[Zope-dev] Re: [Zope3-dev] PROPOSAL: ZODB Relationships

[Tres Seaver]

On Fri, 2003-05-09 at 05:28, Roch=E9 Compaan wrote:
> On Thu, 08 May 2003 19:58:22 -0400
> "Phillip J. Eby" <pje@telecommunity.com> wrote:
>=20
> > At 11:07 PM 5/8/03 +0200, roche@upfrontsystems.co.za wrote:
> > >We finally have a proposal out for ZODB relationships. This proposal
> > >presents an API for relationships, summarises ideas and contributions
> > >from a lot of people and was fuelled by the recent discussions about
> > >relationships on Zope3-dev and Zope-dev.
> > >
> > >     http://www.zope.org/Members/upfront/ZODBRelationships
> > >
> > >Your comments would be appreciated.
> >=20
> > Issues:
> >=20
> > 1. "Global relationship repository" has no use cases, and smells like=20
> > trouble.  Why not just explicitly store the Relationship()=20
> > somewhere?  After all, every RelationshipView will have a reference to=20
> > it.  (For ZODB4, a persistent module might be the natural place to put =
the=20
> > "official" reference to the Relationship(); for ZODB3, just hang them o=
ff=20
> > the root with suitably unique keys.)
> >=20
> > 2. There is no directionality to the associations; this doesn't work fo=
r=20
> > hierarchies or graphs.  E.g. think 'parent_child =3D Relationship()'.  =
That=20
> > won't work.
>=20
> What we have at the moment is a graph and strictly speaking a graph has
> no direction in its edges (maybe you meant directed graph). As far as I
> can see graphs are possible, hierarchies are not. Can't one just use
> containment to represent hierarchies? If one can what other use cases
> are there for directionality in associations?

Dependency:

  - Object 'foo' dependsd on object 'bar'.

Asymmetric business associations

  - Jane is the boss of Fred.

  - Invoice line items decrement the stock count of SKU items.

etc.  I would argue that symmetric (undirected) graphs are much less
common in business applications than asymmetric ones.  =20

> > All in all, I don't see any reason to make this part of ZODB's API or a=
dd=20
> > special repositories to support it.  However, like PersistentDict or BT=
ree,=20
> > relationships might be a nice tool to have available in the ZODB librar=
y.

+1 to that.  I guess I can't figure out what the ZODB has to do with
relationships.

> > A final comment...  Once this takes directionality into consideration, =
you=20
> > might consider calling it an 'Association' rather than a 'Relationship'=
, as=20
> > it would then largely meet the MOF and UML semantics of an=20
> > "Association".  That is, an association is a collection of directed lin=
ks=20
> > between objects.  It would then make sense to refer to refer to the=20
> > 'RelationshipView' as an 'AssociationEnd'.
>=20
> We used the term Relationship because the proposal is based on the
> entity-relationship model. I am not too familiar with MOF so maybe you
> can explain how it will apply to the current proposal. Thanks for your
> comments Phillip. I was hoping you say something because you must have
> thought about this when designing PEAK.

E-R models derive largely from the RDBMS world;  UML class models are
not completely isomorphic with them, but might be a better fit for the
kind of thing you are thinking about (for instance, E-R models generated
from class models often show weird "extra" tables to capture the
oddities of mxn relationships).

Tres.
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com