Re: Should intids be replaced with uuids for relations?

On 3/5/14, 10:57 PM, Asko Soukka wrote:
> Hi,
>
> during the last years there have been some controversy whether to use
> plone.app.relationfield for relations or just save UUIDs into fields and
> catalog them into portal_catalog.
>
> Since plone.app.contenttypes will use relationfields, that seems to be
> coming the official way.
>
> My only concern is that currently relations rely on intids, and we are
> not using them for anythin else (by default).
>
> Yet, it's not zc.relation (the relation catalog) which requires intids,
> but only z3c.relationfield se depend on. So, I'd guess, it should be
> possible to use uuids instead of intids by dropping z3c.relationfield
> (and all intid-packages) and implementing all required counterparts for
> zc.relation and z3c.form directly in plone.app.relationfield.
>
> Would you see issues with this? Is there some other relation roadmap,
> which I'm missing?
>
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.

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)
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.

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?)

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.

------------------------------------------------------------------------------
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

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers