[Zope] Pointer-to-Object Properties

[Jay, Dylan]

> -----Original Message-----
> From: Thomas B. Passin [mailto:tpassin@mitretek.org]
> Sent: Wednesday, November 03, 1999 02:09
> To: zope@zope.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.
> 
> My point is really that object encapsulation and data 
> integrity are very
> important, and it is easy to jump to a design that does not 
> provide for them.
> If we're going to come up with a Zope-ish way let's make sure 
> its design is well
> thought out in these areas.

What you say is very true. Zope's absence of object referencing is a big
omission and one that makes its OO claim somewhat tenuous (along with
independent object identity but thats another issue). As you say doing
referencing well is quite important. 

I think the current tendency to use a central ZCatalog is a good idea. Many
to many references can be made by each object have a search criteria rather
than a list. Then again this means the onus of inclusion is then on the
referred to object rather than the referrer, however the deletion of either
is ok as long as they unregister themselves from the catalog. The referred
object will have to maintain a property/state that means it is included by
the search.