[Zope-dev] Unique and Contant object IDs

[Johan Carlsson]

> > 
> > Is there an unique object ID in the ZODB that remains constant in all times
> > through out the life time of the ZODB?
> > And if so, where is it created and how do I access it? In other word how do I use it?
> > 
> > I can vaguely recall seeing something called OID.
> 
> You can (from python) access the _p_oid attribute of an object to get
> it's OID, but not all that useful. Given an oid, there's no way to get
> back to a useful object. I've thought about patching _setObject to store
> a "hard" parent pointer, thus making it possible to walk back up the
> tree and figure out how to create a properly wrapped version of the
> object as it it had been accessed via it's canonical path. There are
> complications like mountable storages though.
> 
> Unfortunately there are a lot of things that Zope just can't do because
> there is no way to get a persistent "ticket" for an object that can be
> handed out to some external system, and then later redeemed for the
> (properly wrapped) object. Pathnames are not useful, because they don't
> last for the object's lifetime.
> 
> I haven't tried it, but I'm almost positive the semantics of ZServer's FTP
> are a bit wonky because of this. For some other things I'd like to do,
> it's a fatal blow.
> 
Thanks Ty,
It really works for what I intend to do (at the moment anyway).

> > I need it to track discussions related to an object, but stored in a
> > SQL-database. I been pondering a traversal interface in the "commentable"
> > objects, that would give the illusion that the discussion items really are object
> > agregated in the "commentable".
> > 
> > I also guess this could be something ZPatterns could solve in the future?
> 
> For this type of use, ZPatterns can easily solve the problem.
> 
> One way to do this: Make your objects DataSkins-derived, and set up
> SkinScript rules so that when the sql_key property is accessed, a new
> key is generated and the object's sql_key is set to it.  Now, anytime
> you ask for object.sql_key, you either get one it was assigned
> previously (the SkinScript attribute providers are only used if a
> persistent attribute can't be found) or a new one is generated and
> stored in the (persistent) object for future use. 
> 
> Now you can write other SkinScript that keys off of self.sql_key to
> provide access and storage of whatever other attributes from/to SQL.

I was think more in the line of ObjectAttributes aggregated in a DataPlugin
(which in it's turn could use a RDBS for persistent storage).
The reason why I really want this is for letting write intensive persistent objects.
I'm not sure if this solve the problem but it one idea I been thinking about.

Regards,
Johan Carlsson