Edd Dumbill wrote:
On Mon, Nov 01, 1999 at 11:52:20AM -0500, Michel Pelletier wrote:
I suppose the 'right' thing would be for each instance to set an instance attribute when they are instanciated, but you can't do that, because you can't set attributes from DTML, it would violate security. You *can* do it from an external method, but that might be hairy..hmm.
The 'right' thing happens to properties. What I guess I wanted was to be able to add objects in as properties. But of course this is only possible for a ZClass that subclasses ObjectManager, so there won't be anything in the existing Zope interfaces to enable me to do that.
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, this does not account for both authors and books having many more relevant properties. Books have ISBN numbers, synopses, and reviews (not to mention editors); Authors have biographies, pseudonyms, contact information, photos,etc. Someone recently posted an announcement of a 'link' object, but that would have to be added within an object subclassing ObjectManager again. Clearly, what we really need is a 'link' or 'pointer' property, (as well as an equivalent 'pointer-list' type), that can be indexed on by ZCatalog, and will allow properties on the pointed-to objects to be accessed as if they were properties on sub-objects thorugh the 'alias' of the link-property name, and allow them to be indexed on as well. I see this as a very important issue, as the main advantage that ODBs have over RDBMSs is that many-to-many relationships do not have to be decomposed to multiple tables and then recomposed via SQL joins. So I am now offerring to pony up some $$ to get DC to add this to the standard management interface. Provided that this can be added without breaking anything, what would the cost be? Once a ballpark figure has been given, I'll know how much of it I can cover myself, and how much I'll have to raise from other community members. 01 (my two bits), Michael Bernstein.