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.
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
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. itamar@maxnm.com Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C
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
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
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. itamar@maxnm.com Fingerprint = D365 7BE8 B81E 2B18 6534 025E D0E7 92DB E441 411C
In article <9FC702711D39D3118D4900902778ADC8128675@JUPITER>, Toby Dickenson <tdickenson@geminidataloggers.com> 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.
participants (5)
-
Chris Withers -
Itamar Shtull-Trauring -
Johan Carlsson -
Toby Dickenson -
tsarnaļ¼ endicor.com