Re: [Zope-dev] Unique and Contant object IDs
Johan Carlsson wrote: > > > Why are the _p_oid depriciated? > > > > Not depreciated, just "don't use them." > > But I want too, why shouldn't I? > They solves my problems with mapping relational data to objects. I would guess multiple databases can have the same oid's for their objects - and Zope does support multiple databases. Plus you're breaking encapsulation, using an implementation detail of the ZODB for other purposes. -- Itamar S.T. [EMAIL PROTECTED] Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
In article <9FC702711D39D3118D4900902778ADC8128675@JUPITER>, Toby Dickenson <[EMAIL PROTECTED]> wrote: > > Yeah, I'd love an ID I could use to grab an object no matter how often > > it was used. > > I suspect you will have to build this yourself. Store a sufficiently random > id inside your objects when they are created, and use a ZCatalog to index > them. For applications, this is a way to go. For what I have in mind, it's too fragile, and too restrictive. I'd have to make *everything* catalogaware. > > 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... In addition to the other things that Toby points out, for my purposes, as I said, I need a reference that can be given to some external system. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
In article <[EMAIL PROTECTED]>, Toby Dickenson <[EMAIL PROTECTED]> 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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
> Johan Carlsson wrote: > > > Why are the _p_oid depriciated? > > Not depreciated, just "don't use them." But I want too, why shouldn't I? They solves my problems with mapping relational data to objects. If I were to use my own random id generator I would need a global registry for my UID. I really want that to be a feature in the ZODB. //Johan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
Johan Carlsson wrote: > Why are the _p_oid depriciated? Not depreciated, just "don't use them." -- Itamar S.T. [EMAIL PROTECTED] Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
> Chris Withers wrote: > > > > I suspect you will have to build this yourself. Store a sufficiently random > > > id inside your objects when they are created, and use a ZCatalog to index > > > them. How about a ZCatalog that stores its schemas in a RDB? > This is the normal way to keep references to objects. I asked Jim Fulton at > IPC8, and he basically said "don't use _p_oid", which means this is the only > way. Of course, once the observer interface is more well developed you > won't need the Catalog part. Why are the _p_oid depriciated? Are there any plans to come up with a cross storage Universal Object ID schema? As I understand it _p_oid aren't cross storage? > > CatalogAware is the work of the devil anyway ;-) ZPatterns has got to be > > better for doing that kindof stuff ;-) ZPatterns doesn't solve mapping of non Dataskinaware objects. Does ZPatterns rule out an Universal Object ID solution or are they complementary? Regards, JOhan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
Chris Withers wrote: > > I suspect you will have to build this yourself. Store a sufficiently random > > id inside your objects when they are created, and use a ZCatalog to index > > them. > > blech! ;-) This is the normal way to keep references to objects. I asked Jim Fulton at IPC8, and he basically said "don't use _p_oid", which means this is the only way. Of course, once the observer interface is more well developed you won't need the Catalog part. > CatalogAware is the work of the devil anyway ;-) ZPatterns ahs got to be > better for doing that kindof stuff ;-) Yup - no object_reindex() every time you change the object, no need to inherit from anything. You can have automatic catalogging in any DataSkin object trivially, with no change to your class. -- Itamar S.T. [EMAIL PROTECTED] Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
Toby Dickenson wrote: > > > Yeah, I'd love an ID I could use to grab an object no matter how often > > it was used. > > I suspect you will have to build this yourself. Store a sufficiently random > id inside your objects when they are created, and use a ZCatalog to index > them. blech! ;-) > > 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... > > theObject would need to be persistent too. This has a number of > characteristics that I would class as problems, but may be exactly what you > want: > > * theObject will have different acquisuition context when accessed through > its main path, and through self.theobject. This means different: >* security :-( >* absolute_url ...that'd probably behaev how I'd want >* configuration obtained through acquisition. What if theObject is > CatalogAware? CatalogAware is the work of the devil anyway ;-) ZPatterns ahs got to be better for doing that kindof stuff ;-) > * theObject isnt removed from the database when it is deleted from its > folder; this other reference keeps it alive. That, too, would be what I want... although I can think of other situations where that would be bad... argh! cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Unique and Contant object IDs
> Yeah, I'd love an ID I could use to grab an object no matter how often > it was used. I suspect you will have to build this yourself. Store a sufficiently random id inside your objects when they are created, and use a ZCatalog to index them. > 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... theObject would need to be persistent too. This has a number of characteristics that I would class as problems, but may be exactly what you want: * theObject will have different acquisuition context when accessed through its main path, and through self.theobject. This means different: * security * absolute_url * configuration obtained through acquisition. What if theObject is CatalogAware? * theObject isnt removed from the database when it is deleted from its folder; this other reference keeps it alive. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
Toby Dickenson wrote: > > On 24 Oct 2000 15:14:24 GMT, [EMAIL PROTECTED] (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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
On 24 Oct 2000 15:14:24 GMT, [EMAIL PROTECTED] (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 [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
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 _ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
> > > > 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unique and Contant object IDs
In article <000701c03d28$63f28c00$[EMAIL PROTECTED]>, Johan Carlsson <[EMAIL PROTECTED]> 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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
