So the answer of what acts as a reference id for the referred-to object is: "Whatever the best id that your framework provides you is." If your framework is Zope3, a hubid is what you should use. In Zope2, a path or tuple containing (storagename, oid). In ZODB-sans-Zope, an oid (or a (storagename, oid) tuple with the storagename an empty string). I wonder if a single framework could adapt to fit the needs of all 3? It seems doable (different plugins to store the IDs, 'traverse' to the objects), I think... Sean -----Original Message----- From: Shane Hathaway [mailto:shane@zope.com] Sent: Thursday, May 08, 2003 12:15 PM To: sean.upton@uniontrib.com Cc: maxm@mxm.dk; zope-dev@zope.org Subject: Re: [Zope-dev] RFC: RelationAware class for relations between obj ects sean.upton@uniontrib.com wrote:
More in response to Shane than to Max M: I thought that one of the continuing justification for ObjectHubs was that hubids were consistent across multiple mounted storages, but oids were not? How could the universal id problem be addressed at a lower level than Zope2 or Zope3 in this case?
When relationships are applied to Zope, they will always use hub IDs. Outside Zope, mounting and traversal don't always apply.
Then it starts to get amusing. One of the primary reasons for the objecthub was to enable relations. So if the relations get implemented in in ZODB but need some functionality, will it not end up as a duplication of efforts?
Don't assume there is actually any separate effort going on. The point of all of this talk is to discover in what ways the proposed relationship management is insufficient. Once understood, the ideas can come together. Shane