PythonPiece, perlpiece. You can use the Big PP or the little pp!
Is it not just another piece of the puzzle to figure out? :-) Get your Free E-mail at http://tacoma.zzn.com ____________________________________________________________ Get your own Web-Based E-mail Service at http://www.zzn.com
Hi Zen-guys, 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. 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? Best Regards, Johan Carlsson
In article <000701c03d28$63f28c00$ac0aa8c0@tor.torped.se>, Johan Carlsson <johanc@torped.se> wrote:
Hi Zen-guys,
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.
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.
On 24 Oct 2000 15:14:24 GMT, tsarna@endicor.com (Ty Sarna) wrote:
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.
How come? because you want the identity to remain unchanged even after the object is moved? or duplicated? Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
On 24 Oct 2000 15:14:24 GMT, tsarna@endicor.com (Ty Sarna) wrote:
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.
How come? because you want the identity to remain unchanged even after the object is moved? or duplicated?
Yeah, I'd love an ID I could use to grab an object no matter how often it was used. Why wouldn't the following work though: ...in a class method... self.theobject = theObject ...where theObject is something I want a reference to and self is a persistent class... cheers, Chris
In article <04bbvs4ud41is1k7j6f33t67caclscl1jl@4ax.com>, Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
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.
How come? because you want the identity to remain unchanged even after the object is moved? or duplicated?
If the object is duplicated, obviosuly the duplicate is a new one. But a renamed object is the same object, and I want to be able to get back to it, whatever it's called.
Ty Sarna wrote:
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.
Hmmm ... what you describe sounds a lot like an ILU "string binding handle" -- see http://www-db.stanford.edu/~testbed/ilu/ilu20doc/manual_1.html#SEC10 ILU does have a Python binding, and I've been thinking that ILU and Zope might have a lot of potential if used together ... it could make Zope "multi-lingual" .... :^) Has anyone thought of doing anything with the two together? Cheers, -- Steve. oo _\o \/\ \ / ____________________________________________ oo _________________ "Sometime you're the windshield; sometime you're the bug." - Knopfler Stephen C. Waterbury Component Technologies Code 562, NASA/GSFC and Radiation Effects Branch Greenbelt, MD 20771 Engineering Web/Database Specialist Tel: 301-286-7557 FAX: 301-286-1695 WWW: http://misspiggy.gsfc.nasa.gov/people/waterbug.html _________________________________________________________________
participants (6)
-
Chris Withers -
James Johnson -
Johan Carlsson -
Steve Waterbury -
Toby Dickenson -
tsarna＠endicor.com