----- Original Message ----- From: "Michael R. Bernstein" <webmaven@lvcm.com>
Good to know. Thank you. In another email in this thread Steve Alexander did suggest that perhaps a variation on ZPatterns ids within a rack could be used as global id. In addition, I'll try to find some global id routines in C as Robert suggested.
Creating an application specific UID isn't hard: just store the objects of a particular type in a known location, prefix the id with a type identifier (ie: composition), and maintain an int propertyn on the container that gets incremented on each object creation. The objects then get an id of composition00000001 etc. deleting objects does *not* make their ids available, though.
Right. Thread-safety is an issue, though, I think, for the incrementing, but an issue that has been already solved (yay, no wheel re-inventing).
The obvious pitfall is when you ned to distribute the object storage and creation to more than one location per type of object, which is when you need to investigate those GUID routines. In other words approaches similar to ZPatterns Racks don't need a true GUID, but scattering objects throughout the Zope object tree (and on mounted storages) DOES.
Agreed.
[snip discussion of RIDs in the catalog] Therefore, would this proposal be worth anything: Create a class of objects with an integer global id created on initialization. Subclass the catalog to create a catalog that (a) accepts only objects with the global id as a base, and (b) uses the global id as an rid.
The problem here is that Zope allows an object's id to be changed via renaming. Is your proposal going to use the object's id as the GUID, or is the GUID supposed to be a second property (as I was suggesting for the indexable ID property)?
A second property, as you suggested earlier. Read-only. Although in a perfect world the "read only" aspect would merely be indicated in the interface, I seem to recall some Python semi-internals (some double underline tricks) that can intercept gets and sets even if they are attempted directly on the property without an intermediary accessor function. Be that as it may, yeah, a second property is what I had in mind. I think it might work, with the caveat I mentioned that I'm possibly setting myself up for trouble in the future by not working with the ZCatalog as intended. There's no interface, but it still seems pretty clear that I'm going beyond the bounds of what was intended. I think it's potentially worthwhile though, and would be willing to go to bat with ZC to see if they like the idea if it works for me in prototype and some other folks like it ok. Allowing it in the ZCatalog interface would not be a big deal, I think--but my perspective is pretty darn limited so I could easily be wrong.
It is however, important to realize that in this approach, the referring object contains all the information regarding the relationship, the referred object just infers the relationship info using the Zcatalog.
Yes; actually, though I was thinking of making use of a mix-in class (i.e. I started coding such a quick basic mix-in a day last week) that would keep the info in both objects. Data integrity issues, I know...the forward link would be the "true" link and the back link would be the disposable (and read-only) cache, should I need to code a reindexing or a validity check of the back links at some point...seemed easy enough and, for my app, not unacceptably risky. At least worth prototyping.
Hmm. If your mix-in class created a general purpose ZMI tab for managing these relationships (and an associated API), I would be *very* interested in this, even if it didn't allow traversal into the associated objects (which can be accomplished using SkinScripts).
Sounds good. :-) I'll see what I can do. :-) It requires...well...it requires "efficient and flexible object references". With all this discussion I have some good ideas on how to move forward. Thanks again. Gary