RE: [Zope-dev] RFC: RelationAware class for relations between obj ects
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
sean.upton@uniontrib.com wrote:
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...
Yes, it would be elegant and I don't think it would be complicated at all. For Zope 2, I think you'd either use a path or a hub ID (assuming the object hub gets backported. ;-) ) Shane
In Zope applications, it is never a good idea to refer to oids from the application level because they can change out from under you at arbitrary times, such as rename, cut/paste, export/import, etc. This is one of the basic reasons why ObjectHub exists, as Shane eluded. -Casey On Thursday 08 May 2003 03:27 pm, sean.upton@uniontrib.com wrote:
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
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
participants (3)
-
Casey Duncan -
sean.upton＠uniontrib.com -
Shane Hathaway