On 19 Aug 2001 18:31:43 -0400, Gary & Karyn wrote:
----- Original Message ----- From: "Michael R. Bernstein" <webmaven@lvcm.com> <snip quote from me about GID and ZPatterns>
With ZPatterns, you're basically only getting separation of application logic from storage, with some extra neat things like skinscripts that make application logic easier.
If you want the retreival of meta-data without waking up the object, you still need to layer on the global unique id with ZCatalog on top of ZPatterns.
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. 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.
[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)?
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). Michael Bernstein.