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
> 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
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.
> >>>>/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.
> 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
Zope3-dev mailing list