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 _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
