Re: Should intids be replaced with uuids for relations?

> Using intids as the keys for catalog indexes is ideal and was done intentionally, because integers can be compared more quickly than strings, so IOBTrees are faster (at least, that's my understanding of why intids were used). This is also one reason the ZCatalog uses an integer rid (record id) internally instead of some other identifier.

That explains it, IMO, it should be internal for catalog, not stored in RelationValue as the only way to figure out the target object.

So zc.relation requires integers as docids and that's why it would not be trivial to use uuids instead. That was the part I missed.

Unrelated to this, but outside Plone I've used oids as (zope.)index docids to avoid keeping separate intid -> object -mapping (of course losing the object context during retrieval). Haven't seen issues... yet.

> I'm not a fan of indexing relations in a separate catalog though. My objections are:
> 1. A specific objection about the indexes set up by z3c.relationfield: it indexes interface objects rather than their names, which means the indexes break if the interface is removed from the Python environment (due to uninstalling an add-on, for example)

That was new to me. Scary indeed. (Should experimental.broken help with these or is it limited to similar issues with component registry?)

> 2. A general objection: Having multiple catalogs limits the kinds of queries you can do (for example, you can't easily ask for all the items with portal_type X that have a relation to item Y), means some data gets indexed multiple times (which is inefficient), and means developers have to learn 2 different catalog APIs.

Agreed.

> What I would like to do instead is implement a special kind of ZCatalog index, a "RelationIndex", which automatically finds and indexes all references (whether they are Archetypes references or z3c.relationfield RelationValues). This could then be queried as part of normal catalog queries like:
> 
>    catalog.searchResults({
>           'portal_type': 'Document',
>           'relations': ('related_item', ' 8c30e8f6173147408079b94d49c68e00'),  # (reference type, target UID)
>    })
> 
> (I actually have a proof of concept of this implemented, but it needs more work that I haven't found time for. Want me to post it on github?)

Please, do.

I started this thread, because I need a generic TTW addable relation field for dexterity types later this year.

So I could just implement a field that stores simple (reference_type, plone.uuid) -tuples (or lists of tuples) into objects and then those values would be indexed into the new index. I guess, custom RelationValue-objects would be too much overhead.

... and much later comes all the linkintegrity requirements.

> On the other hand, this approach would make it harder to have relations to and from objects that are not full-class content objects in the folder hierarchy.

And then one should use zc.relation with custom intids or zope/five.intids again.

There are also some other features in zc.relation (like relation events), but I guess, most of the use cases could be fulfilled without zc.relation, z3c.relationfield and zope/five.intid.

Regards
Asko
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk