Re: Should intids be replaced with uuids for relations?

Laurence Rowe wrote:
>
>     References should be stored canonically on content items as a
>     uuid, that allows you to rebuild your catalogue when necessary.
>     For dexterity, I just used
>     the plone.formwidget.contenttree.source.ArchetypesContentSourceBinder
>     for my relatedItems fields, even in dexterity only sites. One
>     field for each relation type. It felt much more robust. You could
>     then index the uuid values in the catalog using a KeywordIndex to
>     give you the ability to find back references. Storing them as
>     python integers would be more efficient, though they'll still end
>     up in OIBTrees as they're > 32 bits.
>
>
> That would now be known as the UUIDSourceBinder nowadays...

I recall reading Laurence's comments also before and them being one of
my reasons for using UUIDs (and mostly UUIDSourceBinder) instead of
plone.app.relationfield.

Again, I'm raising this issue, because p.a.contenttypes ships with
plone.app.relationfield-based related items behavior enabled for default
types. Of course, because it's a behavior, it can be swithed off, but it
would still be nice to have one recommended way for creating behaviors.

Laurence's approach combined with David's generic RelationIndex sounds
like a working approach for me. I'm still thinking of a TTW addable
field type, so multiple relation fields could be defined with
schemaeditor. Would it be too much magic to get the relation type from
field name and store only UUIDs into objects? (Or should it be possible
to define relation type separately from field naem and then store type,
uuid -tuples instead?)

Also, plone.formwidget.contenttree is kind of deprecated from
plone.app.widgets point of view and similar utilities should probably be
(and may already exist) in plone.app.vocabularies.

-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