[Zope] [Catalog/ZCatalog] external RID references: bad idea?

[Gary Poster]

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