[Zope3-dev] Support for relations in Zope

[Dario Lopez-Kästen]

Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
>> Janko Hauser wrote:
>>> I'm in support of most of your points, although I do not see that the 
>>> catalog is actually proposed as an alternative. Jim's suggestions 
>>> were more directed to store things in each other. Or reference them 
>>> somehow, but not by an indirection with a central index.
> 
> 
> Thanks Janko. :)
> 
> 
>> My intuition is that if you store "things in each other" you have
>> implicitly created an index as soon as the objects get cataloged.
> 
> 
> I don't see how.  You only have indexes for the information that gets
> cataloged. Janko summarized my position very well.
> 
> I'll note that I'm not opposed to "relations".  I'm not even opposed
> to a centralized store for relations.  I am inclined to limit their use
> to where they are needed and in leveraging the component architecture
> to make it easy to change one's mind.
> 

Caveat: I have not really followed the thread to it's full extent, nor 
have I done any significant work on/with Zope3 yet; consequently (sp?), 
I  am not sure if the "things" mentioned above are general things, i.e. 
arbitrary objects, or only "things" specific to portlets, and the models 
related to this particular problem. Also I am no ZODB expert.

With that in mind, I offer my sincere apologies if I am beating a dead 
horse or missing the point entirely. The discussion above triggered my 
curiosity about relation-support in Zope, being the reason I write this :-)

So here is my take on relations and Zope:

In general, I would like to see Zope have some way to, or provide basic 
support for applications to, create relations between objects - the term 
"relation" is in this context defined losely as the most basic idea of 
relation. No need for ACID, foreing constraints, etc. Just plain old 
simple "X is related to Y, and it is expressed as Z" without any 
particular meaning of what the relation X-Y means - that interpretation 
would be up to the particular application being built, and Z would be 
the actiual "implementation", oway of actually creating the X-Y relation.

I have several use cases where the basic Zope relationship between 
objects, containment, is too limited and just cannot be applied.

The ZODB, AFAIK, supports only relations by interpreting containment as 
a kind of relation, and the way to access an object is to traverse to it 
from the root. While it is possible to create relations between objects 
allready in Zope, these objects either cannot be moved/deleted, nor can 
they be renamed if we want to maintain the relation.

I believe that if Zope is to provide support for relations (which I 
would like to see :) it needs to have more  plumbing to help sort out 
some practical problems that exist.

To avoid the "oops, object moved - relation broke" problem, a simple, 
yet I belive totally sufficient, solution is to implement a centralised 
index of _all_ objects. Each and every object in the ZODB, without 
exception, is indexed and may be referenced by looking it up in the 
index. This implies at least the following changes:

- this "master" index is maintained automagically. It is always there 
and is being constantly updated, whether you want/use it or not.

- objects will have to be tagged with a unique internal id, UUID, 
read-only, somewhat similar to the concept of ROW-IDs in relational 
databases. This is not the id of an object as we know it now, where we 
can rename an object, thus changing it's ID. This is a 
system-maintained, read-only id, guaranteed to be unique in the ZODB 
(read "unique across mounted ZODB storages" as well). This  UUID is what 
the master index uses to reference objects.

- all object manipulation commands need to be enhanced so as to support 
the "master" index. If I create/rename/move/delete/and-so-on an object, 
then the "master" index is updated accordingly, transparently. Note that 
the master index not necessarily needs to support undoing (in fact it 
may just be plain wrong for it to support undoing). It just has to 
reflect the current state of the ZODB and no more.

Using this we can then create relations (implementation agnostic) 
between arbitrary objects with the help of the "master" index  using the 
objects' UUID to reference them. The relation will hold through any 
change in the object, except the deletion on an object. With the help of 
the "master" index we have the information needed to build and enforce 
constraints, build and maintain integrity rules, etc.

If the idea of having this at the Zope Level is too overwhelming, then 
perhaps it is easier to create special container objects (ie. folders) 
that may be used as the starting point for applications. Inside these 
folders, the above applies.

Of course I have no idea of how hard this would be to actually implement.

There are several current zope-projects/solutions that IMHO would have 
benefitted from having access to at least part of the above plumbing, 
and for instance both CPS and Plone have implemented some of the above 
ideas in different ways.

I do not believe that it would not be necessary to implement the above 
as a new kind of ZODB storage. I rather see it as something that is 
created and maintained at the application level (the application in this 
context being zope) or perhaps between the storage and application 
level. Best would be to have the ZODB maintain it as part of it's 
design, but I guess that would be too much work.

The actual nature of relations then can be left to the 
desinger/implementor to desing. For my particualar needs, it would be 
nice to have a standard relation-object that is configurable to create 
and maintain several kinds of relations, but I am perfectly happy with 
maintaining my own kind of relation-objects (or equivalent).

These relation-objects could then be used both in component level design 
(for example when Jean-Marc needs to maintain relationships in CPSSkins) 
and in application level design (for instance when I need to maintain 
groups of objects where each object may be anyplace in the ZODB and in 
several groups simultaniously).

The nice part of this is that this does not dispute nor question the 
standard "containment" realtion that we now have implicitly in the ZODB, 
though I am not sure if that particular kind of relationship should be 
expressed as a relation-object.

What are your thoughts?

Thanks,

/dario

-- 
-- -------------------------------------------------------------------
Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.
Lyrics applied to programming & application design:
"emancipate yourself from mental slavery" - redemption song, b. marley