[Zope-dev] Efficient and flexible object references

[Michael R. Bernstein]

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.