Hi. Faced with a need to make large numbers of references to objects within other objects, wanting to get certain information about the linked objects without waking them up in the ZODB, etc., and wanting to store the references efficiently, I thought that the Catalog might be an avenue to explore, since it had solved some somewhat similar issues. So I studied it. Interface declarations will make these kind of questions a bit more straightforward in the future, but for now... My question: Would it be a bad idea to use a given object's catalog RID to store an object reference (elsewhere), and then using the RID to get the UID, the metadata, and or the actual object as needed, using standard ZCatalog methods (getobject, getMetadataForRID, getIndexDataForRID, getpath, etc.)? [If this isn't too bad of an idea, then I will have to subclass ZCatalog to add a method that calls _catalog.hasuid for a given object's physical path--this will return the RID.] [If this is actually approaching a good idea, I would propose to ZC to add a clear interface-happy getRID in catalog and ZCatalog] Risks I see: primary one is that, unless I get ZC's blessing on this and a clear addition to the (nonexistent?) catalog/zcatalog interfaces of the needed getRID function, this is a hack. I'd be relying on the internal workings of the catalog staying the same. secondary risk I see, and I hope not a problem, is that I'd have to be waking up the catalog every time I needed to mess with any reference in my objects. I'm hoping that this won't be a problem merely because the catalog is such an integral part of the inner workings that it will always be "awake". I would really appreciate any thoughts or concerns about this approach. Thanks Gary