[Zope-dev] RFC: RelationAware class for relations betweenobjects

[Romain Slootmaekers]

Shane Hathaway wrote:
> Roch=E9 Compaan wrote:
>=20
>> * Shane Hathaway <shane@zope.com> [2003-04-30 16:55]:
>>
>>> Do you agree with these requirements and minimal use cases?  Is there=
=20
>>> anything I need to clarify?
>>
>>
>>
>> This sounds good. Now what is the next step? I'd like to help build on
>> the API or aspects of it like making it work in Zope 2 for instance. I
>> like the idea of having RelationShips as a separate branch in the ZODB
>> that you posted earlier.
>=20
>=20
> Well, I think we should look at the way relationships get stored.  Righ=
t=20
> now I can think of two possible models:
>=20
> - Store and index relationship objects.  This is perhaps the most=20
> obvious way to do it.
>=20
> - Use relations (database tables) and infer relationships rather than=20
> store them.  This could allow us to take advantage of relational theory.
>=20
> The advantage of storing relationship objects directly is that it's=20
> obvious.  When you want to relate object A to object B, you just create=
=20
> a Relationship object that links A and B and store it.  You can store=20
> extra metadata by creating your own relationship classes.  Relationship=
=20
> objects need only implement a minimal interface.
>=20
> The disadvantage of storing relationship objects is that every=20
> relationship is stored as a separate object.  But in a complex=20
> application, aren't there potentially far too many relationships to=20
> enumerate?  How would we manage this?  And would it be possible to infe=
r=20
> relationships?
>=20
> The advantage of using relations is that it gives us the benefits of=20
> relational theory.  Relational theory provides a clear way to store and=
=20
> query relationships efficiently.  It lets you infer relationships based=
=20
> on explicit relationships.
>=20
> The disadvantage of using relations is that relationships have to be=20
> decomposed for storage.  You can't just add an attribute to a=20
> Relationship object and expect it to be stored; you also have to arrang=
e=20
> for the corresponding relation to store another column.  (Although you=20
> might automate the process by telling a relation to keep its schema in=20
> sync with a particular class.)
>=20
> Either solution provides a way to store and retrieve simple=20
> relationships.  The difference is in the way they can expand.  I like t=
o=20
> imagine that the relational model was developed for the purpose of=20
> scaling the entity relationship model, but that's a wild guess.
>=20
> I suppose mxmRelations stores relationship objects directly.  A ZCatalo=
g=20
> instance, on the other hand, is much like a relation, although it=20
> doesn't implement all the same operations and provides some extra=20
> operations.
>=20
> Shane

We (@zzict) implemented something that was "RelationAware" some time=20
ago, and found it to be non trivial, and a pest for the ZODB.

What happens is this:
[first some Notations A,B,.... objects
R(A,B) is an object associating A and B, basically having a reference to=20
  A and B. ]
If A or B move (cut & paste fe) you should update R as well, but if you=20
install backpointers, then you end up having a spaghetti of entangled=20
objects so that if 1 is "pumped up" from storage, the whole mess gets=20
pumped up... and cached.

You can try to have a name based binding to decouple things, but it is=20
far easier said than done,especially with cloning etc...

Anyway, we ended up moving our whole object model to some RDB (also for=20
scalability and other reasons). As a consequence, designed relations our=20
now trivial, but ad hoc relations impossible, which is ok for us, but=20
might not be for you.


Hope this might help your decisions.

Romain.