[Zope] Pointer-to-Object Properties

[Toby Dickenson]

> -----Original Message-----
> From: Thomas B. Passin [mailto:tpassin@mitretek.org]
> Subject: Re: [Zope] Pointer-to-Object Properties
> 
> From: Toby Dickenson <tdickenson@geminidataloggers.com>
> 
> >> From: Michael Bernstein [mailto:mbernstein@profitscape.net]
> >
> >> It would be very beneficial to be able to 'point' to
> >> arbitrary objects as if they
> >> were sub objects, thus enabling one-to-many, many-to-one, and
> >> many-to-many
> >> relationships not constrained by the object heirarchy.
> >>
> >> Classic example: Many author objects, many book objects.
> >> Authors can have written
> >> several books, and certain books are collaborations with more
> >> than one author. It
> >> does not make sense for books to be contained within authors,
> >> or authors to be
> >> contained within books.
> >>
> >> While this simplistic scenario would allow us to either
> >> assign a list property
> >> with  book titles to an author object, or a list property
> >> containing authors names
> >> to a book object, and live with the small amount of
> >> duplicated data
> >
> >I think the key observation here is that the additional information
> >should be sufficient to identify the foreign object.... then the
> >pointed-to object can be located by searching a Catalog.
> >
> 
> Many-to-many relationships are always tricky.  As others have 
> pointed out in
> this thread, it is highly desirable to have some means to 
> maintain data and
> referential integrity.  In SQL this is done by declaring 
> create-delete-update
> rules for each foreign key relationship.
> 
> Also, you want to make keep the properties of the two types 
> of objects in the
> many-to-many separate, to minimize coupling.  In the case of 
> books, one way to
> do this is to have a book maintain a list of its authors, and 
> each author to
> maintain a list of its books.  Then a book and an author only 
> need to know about
> lists, not about authors and books.  You can delete a list 
> item without deleting
> its parent object.  But now, if a parent object is deleted, 
> how do you make sure
> all references to it in various lists are also deleted?  Not 
> so easy!  Back to
> data integrity again.

A small step up from this is to replace the second list (a list
of authors in a Book object) with a Catalog. The Book can determine all
of it's authors by searching the index of 'book-list' properties.

With this change you never break data integrity by changing the list,
although it is possible to break it by deleting a Book.