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

[Jean-Marc Orliaguet]

Helmut Merz wrote:

>Am Freitag, 11. November 2005 18:00 schrieb Jean-Marc Orliaguet:
>
>  
>
>>I was thinking more about the policy of assigning unique ids
>>to objects in a relation. It's the application that really
>>should decide about that policy.
>>    
>>
>
>in fact the unique ids aren't "assigned" to the objects (the 
>objects aren't touched at all) by the IntIds utility - if you 
>have registered a local IntIds utility they are just created in 
>the utility driven by the IObjectAdded event. So this IntIds 
>stuff should not interfere with anything else and the 
>application should not be concerned at all about it.
>  
>

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.

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.

>>>>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. My impression is that
you are thinking of a reference engine rather than a relation engine
with the difference compared to the Archetype's engine that references
are stored outside the objects.

/JM