Which approach for storing external ID of related resources - custom document schema or dc:relation?

Hello,

I have a situation where an external system's design requires it to generate its own identifier for documents that we originate in Nuxeo. However, to perform certain activities in Nuxeo, our custom extension needs to use that external identifier in some operations. So we must store this identifier in the Nuxeo document somewhere.

My question: is it better design to add a special field to our document type to contain this external ID, or should I use the Relations tab to capture this information? I looked at the Dublin Core site and decided that hasFormat describes the relationship. The identifier is not a dereferenceable URI, but it does have a custom URI scheme prefix.

I like the idea of using Relations because it doesn't tie me to a custom document type, but I am curious if I will be able to use NXQL or similar to discover all the documents where a relation matches a predicate and its value matches a prefix string (the custom scheme). I am also wondering if there are any drawbacks to using a relation field for storing this information that might not be obvious.

Thanks for any advice.

0 votes

1 answers

1850 views

ANSWER



Nuxeo has a standard field named uid that you should use for this. It's unused but present in all document types by default and designed for this kind of use.

Relations could work but the storage and query are much more complex, so slower.

1 votes



Thanks. I have seen the uid:uid (for example on http://doc.nuxeo.com/display/Studio/Configure+the+ID+generation+using+functions) – the trouble is that the uid is just a single string instead of any number of UIDs, from what I can tell.

We already have a "human-readable" ID in that field, but this external system's identifiers are long strings of hex digits. What I effectively need is a list of other unique identifiers attached to the document to be used in various contexts when interacting with other machines.

05/02/2014

In that case a multi-valued specific field in a custom schema would be best.
05/02/2014

Thanks, I will accept this answer because it is good general advice.
05/02/2014