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