[Zope-dev] Efficient and flexible object references

[Gary & Karyn]

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

<snip quote from me about XLink>
<snip more discussion about GID>

I was thinking this morning, however, that it still is a small shame that
the RID can't be used--or, perhaps more obviously, that Zope objects don't
have a GID assigned automatically, and then this GID is *used* as the RID.
The advantage of the RID logic is that, within the catalog, the code is just
about as quick as possible: pass a RID into the catalog, and it looks it up
in a btree and gives you the UID; pass a UID, it looks it up in a btree and
gives you the RID; pass an RID for the metadata and it just looks it up in
the metadata dictionary and gives it to you.  If RID equaled GID that would
be extremely efficient.

Instead, the GID approach now still must iterate through all of the ZCatalog
indexes to get an RID in all cases.  Therefore, getting metadata is passing
a GID, looping through all indexes (in an optimized way, I am aware, but
still), finding the RID, and *then* looking it up in the metadata
dictionary.  At the very least, even if the loop through the other
irrelevant indexes is so optimized that it adds insignificant time, you are
doing two lookups (GID->RID->metadata) when you could have done one,
presumably nearing at least a double in processing time?  I claim no great
knowledge in this area but I can't help but find it logical.

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 gain in efficiency would be offset by a loss in future-compatibility,
unless this seemed like such a reasonable answer to the very basic concerns
you raised in your 1999 post that it could be turned into an actual product
proposal.  Just another idea, I suppose...

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

> HTH,
>
> Michael Bernstein.
>

It did indeed.  Thanks.

Gary