[Zope3-dev] Yet Another Relations (aka Reference) Engine...

[Helmut Merz]

Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet:

> The good thing about IntIds is that it leaves the objects
> untouched, the bad thing is that it creates a hard coupling
> between the integer id that is used to *refer* to the object
> and the key that is used to *represent* the object in the
> relation. These are really two different aspects.
>
> In cpsskins when objects are set in relation, it is the
> application's responsibility to tell the engine how objects
> will be identified in the relation, i.e. with a unique id
> (IntIds), or with a URI or a with a name (that may be share
> between several objects) ... The relation engine then stores
> this key as well as an internal reference to the object.
>
> so for each object put in relation we have:
> - a key (used by the application to query the engine)
> - a reference to the object (used internally by the relation
> engine to get the object)
>
> the application only "sees" the keys until the objects get
> dereferenced.
>
> But no 1:1 mapping between the key and the object is imposed
> by any external IntIds utility. Which make it possible to ask
> the engine: "give me all the portlets associated to the 'left'
> slot" even though the 'left' slot is materialized in more than
> one instance.

Hm, I'm not sure I understand - so it's not the object (more 
precisely: its unique id) that's indexed but some value provided 
by the object - so this is indeed some sort of an attribute 
that's indexed.

This I would prefer to solve using relation objects that 
explicitly handle additional attributes (provided by the objects 
that are connected by the relation) that may be indexed *in 
addition* to the unique ids.

Or let's see this way: The keys (unique ids in the standard 
implementation) are retrieved by an adapter to the relation 
class (providing IIndexableRelation) so this adapter could 
provide something else if necessary.

> In your implementation only objects that are identified
> uniquely can be put in relation, and it doesn't seem to be a
> design choice other than a limitation imposed by the catalog.

Yes, it is a limitation of the default implementation but I'm 
still not sure it is bad, and it can be overcome easily.

> >>>>http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches
> >>>>/j mo -perspectives/storage/relations.py
> >>>
> >>>I read this, and it indeed gave me the impression that it
> >>>might be a not so bad idea to use a catalog ;-)
> >>
> >>well, you haven't written the catalog indexes yet :-)
> >
> >I needn't because I just use the FieldIndex from zope.index.
>
> I understand, but the idea is to index relations, not simply 
> the references between in the objects put in relation. 

ACK

> My 
> impression is that you are thinking of a reference engine
> rather than a relation engine 

Maybe I just don't see the difference... (There is one, of 
course, but I doubt it is really of relevance in a practical 
context. )

Helmut