[Zope-dev] Efficient and flexible object references

Gary & Karyn Gary & Karyn" <garykaryn@earthlink.net
Sun, 19 Aug 2001 21:41:21 -0400


----- 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