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. See also: http://www.zope.org/Members/michel/Projects/Interfaces/Traversal and http://www.zope.org/Members/michel/Projects/Interfaces/ObjectPublishing