> I'm looking for an internal globally unique identifier for
> objects in my
> Zope store.
The object path would be that.
> I know that I can use id=object.absolute_url() to create an
> identifier and
> then <something>.resolve_url(id) to recover the object from
> the identifier
> -- but I have two problems with this API:
> 1. The URL is not really a global identifier, as resolving it seems to
> depend on the <something> from which I call resolve_url().
> In particular,
> if the id is created when Zope is running normally (as a service), and
> resolved when running Zope from the command line debugger, the resolve
> fails. This is not good.
Yes, the REQUEST object is not available during a command line session.
This can be a real pain.
What you can do is (in Zope 2.2) use 'unrestrictedTraverse()' and
'restrictedTraverse()' in combination with the string.split() of the
relative URL as obtained via ob.absolute_url(relative=1), e.g.
ob = self.myob
oburl = ob.absolute_url(1)
obpath = string.split(oburl, '/')
obpath.insert(0, '') # a null string as the first item in the
[un]restrictedTraverse list means relative to root
sameob = self.unrestrictedTraverse(obpath)
(this is untested, I think it's right...)
> 2. The need to locate an object <something> carrying the resolve_url()
> function is a problem; in particular, I would find it helpful
> if I could
> resolve my global identifier from within a __setstate__()
> method (where I
> have no access to local Zope variables), so I really want a
> genuinely global
> function for resolving my id.
> Any suggestions, or do I have to dig into the (disagreeable
> and uncommented)
> bowels of Zope and write my own?
Well... if you don't plan on using mountable database features within
Zope, each Zope object will have an attribute "_p_oid", which is the
64-bit object id (stored as a string) that is used by the storage to
keep current and historical revisions to the object. It's not
recommended that you base an extensible system on this attribute,
however, because using multiple storages within a single Zope instance
(such as when you use mountable databases) almost guarantees that this
identifier will not be unique. I believe that mountable databases in
Zope will quickly become a common implementation practice.
I wouldn't suggest writing your own GUID generator for general-purpose
Zope objects. I would promote the use of [un]restrictedTraverse and use
the object path as a unique ID.
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -