-----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.
"Jay, Dylan" wrote:
From: Thomas B. Passin [mailto:tpassin@mitretek.org]
From: Toby Dickenson <tdickenson@geminidataloggers.com>
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.
<stuff about SQL snipped>
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.
There is a problem with letting reffered-to objects manage their incoming pointers. It means that a user that wants one of their objects to point to another object must either have management priveleges on the referred object or must get another user who does to do it for him. You could add a special permission 'Add incoming pointer' could be added to the object and made widely available, but the equivalent 'delete incoming pointer' permission would still have to be tightly controlled for obvious reasons. Hmm, I guess you could jigger things so that pointers to objects could be managed by the owners of the referring object, even though they're contained within the referred-to object, but that seems to be getting needlessly baroque. Ha! I've got it! Proposal outline and handwaving follow: Create a bi-directional 'relationship' object (in two flavors; one-to-many, and many-to-many) that both the referring AND the referred object find through ZCatalog, and add a simple 'manage relationship' permission to the referring and referred-to objects which grants them access to it. Add a standard 'Relationships' tab to the management interface. Relationship objects should not be contained in either the referring or referred to objects, and perhaps should not be visible in the management interface at all, except through the 'Relationships' tabs of objects. Define names and types of relationships in the ZClasses (maybe also whether they are required or optional) as well as what Meta-types each side of the relationship may be. Relationship enabled objects get 'manage relationships', 'view relationships' and other associated permissions. In this way, objects can manage their relationships with other objects, no user needs to have permissions on another users objects, properties are not bent out of shape, and objects are not required to be ObjectManagers. What do you guys think? Would this work? Can we also get traversal to work through the 'alias' of a relationship name? 01 (my two bits), Michael Bernstein.
Michael Bernstein wrote: [snip]
Ha! I've got it! Proposal outline and handwaving follow:
Create a bi-directional 'relationship' object (in two flavors; one-to-many, and many-to-many) that both the referring AND the referred object find through ZCatalog, and add a simple 'manage relationship' permission to the referring and referred-to objects which grants them access to it. Add a standard 'Relationships' tab to the management interface.
I think we're on the same track, see my XLink ramblings from yesterday: http://lists.zope.org/pipermail/zope/1999-November/013235.html This is preceisely the kind of thing XLink was designed to solve. There are a few reasons for using XLink syntax rather than rolling our own... * The W3C working group has done all the thinking about what these kinds of links should be able to do. * It's a standard (still draft, but it will be final eventually :). * When browsers support XLinks (Mozilla does a little) you can just expose your XLink data to the browser and let it do what it wants with them. (Read up on link collections in the spec to see what you could do with a catalog full of links and an appriately formed header on an XML document.)
Relationship objects should not be contained in either the referring or referred to objects, and perhaps should not be visible in the management interface at all, except through the 'Relationships' tabs of objects.
Out of line links! The Relationships tab could be there for classes that are aware of their (incoming and outgoing) links just so you can see these things in the management interface.
Define names and types of relationships in the ZClasses (maybe also whether they are required or optional) as well as what Meta-types each side of the relationship may be.
This is basically handled by the role attribute on XLink locators. They don't dictate what kind of objects can be pointed to, but I don't really see the advantage of that. The important part is agreeing on the semantics of a role (i.e., what 'author' means)... if you happen to point to an object that understands what that means, great, if not then someone else probably does and wants that information.
Relationship enabled objects get 'manage relationships', 'view relationships' and other associated permissions.
A convenient way to write/edit XLinks. I like it. :)
In this way, objects can manage their relationships with other objects, no user needs to have permissions on another users objects, properties are not bent out of shape, and objects are not required to be ObjectManagers.
You just summed up the purpose of out of line links. :)
What do you guys think? Would this work? Can we also get traversal to work through the 'alias' of a relationship name?
I like it. And, yes it would work. I'm not sure I understand your third question. (BTW, please tell me if my ramblins make any sense or not, thanks. :) -Otto.
Otto Hammersmith wrote:
Michael Bernstein wrote: [snip]
Ha! I've got it! Proposal outline and handwaving follow:
Create a bi-directional 'relationship' object (in two flavors; one-to-many, and many-to-many) that both the referring AND the referred object find through ZCatalog, and add a simple 'manage relationship' permission to the referring and referred-to objects which grants them access to it. Add a standard 'Relationships' tab to the management interface.
I think we're on the same track, see my XLink ramblings from yesterday: http://lists.zope.org/pipermail/zope/1999-November/013235.html
Hmm. thanks for the pointer, I missed it first time 'round. The XLink spec was VERY interesting reading. Mostly it seems as though it deals with how to express (render) in XML the type of non-hierarchical structures we're discussing, and provides a good source for use-case scenarios. The question remains "How do we implement this data in the ZODB and management interface?".
This is preceisely the kind of thing XLink was designed to solve. There are a few reasons for using XLink syntax rather than rolling our own...
* The W3C working group has done all the thinking about what these kinds of links should be able to do. * It's a standard (still draft, but it will be final eventually :). * When browsers support XLinks (Mozilla does a little) you can just expose your XLink data to the browser and let it do what it wants with them. (Read up on link collections in the spec to see what you could do with a catalog full of links and an appriately formed header on an XML document.)
Well, while exposing XLink-type information to the client as an excellent goal, and should certainly be taken into (very serious) consideration, I am more interested at the moment with making this type of information available to server-side applications.
Relationship objects should not be contained in either the referring or referred to objects, and perhaps should not be visible in the management interface at all, except through the 'Relationships' tabs of objects.
Out of line links!
The Relationships tab could be there for classes that are aware of their (incoming and outgoing) links just so you can see these things in the management interface.
This was the most interesting part of the XLink spec for me, in that it validated a notion percolating through my brain that objects do not neccessarily have to be aware of their incoming links at all. Implementation-wise, this means that only Classes and objects that inherited from a 'relationship-aware' base class would display the 'Relationships' tab in the management interface.
Define names and types of relationships in the ZClasses (maybe also whether they are required or optional) as well as what Meta-types each side of the relationship may be.
This is basically handled by the role attribute on XLink locators. They don't dictate what kind of objects can be pointed to, but I don't really see the advantage of that. The important part is agreeing on the semantics of a role (i.e., what 'author' means)... if you happen to point to an object that understands what that means, great, if not then someone else probably does and wants that information.
Well, you're correct that the client-side applications you're thinking of do not require this sort of feature. However, for an web interface that allows you establish these relationships (ie: create XLinks) implementing an 'Object picker' that is constrained by the object's meta-type is fairly important, and should not have to be re-implemented from scratch for each application. Putting the constraints in the Relationship Object instance seems like a convenient location.
Relationship enabled objects get 'manage relationships', 'view relationships' and other associated permissions.
A convenient way to write/edit XLinks. I like it. :)
In this way, objects can manage their relationships with other objects, no user needs to have permissions on another users objects, properties are not bent out of shape, and objects are not required to be ObjectManagers.
You just summed up the purpose of out of line links. :)
What do you guys think? Would this work? Can we also get traversal to work through the 'alias' of a relationship name?
I like it. And, yes it would work.
Ok, this is a Good Thing.
I'm not sure I understand your third question.
Let me give an example of what I mean: In the DTML of the default method for a book object that has a defined relationship called 'Author' to a 'Person' object (which has a 'FullName' string property), I would like to place a DTML snippet that said <dtml-var Author.Fullname> and have the final document render the pointed-to object's 'FullName' property, even if the 'Book' object has one as well(unlikely) or could acquire one from somewhere (possible). The chief advantage to containing 'pointers' within the objects themselves is that it makes implementing this easier (Re: http://lists.zope.org/pipermail/zope/1999-November/013215.html).
(BTW, please tell me if my ramblins make any sense or not, thanks. :)
Yes, you make a lot of sense, and when more browsers are XML aware, the XLink syntax will be very important for moving some of this stuff onto the client, instead of leaving it all on the server. On the other hand, this might be even more important in the interim when considered in combination with XML-RPC for moving more complex data between servers. (cue blue sky music). 01 (my two bits), Michael Bernstein.
participants (3)
-
Jay, Dylan -
Michael Bernstein -
Otto Hammersmith