Hi Chetan That would be really troublesome for multiple reasons.
First of all nt:resource doesn't allow for residual properties as it comes with defined set of property definitions. So, any attempt to write a jcr:uuid property to such a node will fail. Second, for other nodes that allow for residual properties (such as e.g. oak:Unstructured), the declaring node type for such an jcr:uuid property and thus the property definition itself would change leading to very nasty problems, when you later try to add mix:referenceable mixin type. See e.g. OAK-2164, JCR-2779, OAK-2121, OAK-2246 (and maybe more). So far our claim has always been that jcr:uuid is a reserved property that must never be used for any other property than the autocreated, mandatory, protected property defined by mix:referenceable. Really, I don't think that this would be feasible... and just for the record: I am pretty sure that there was good intention behind the change in nt-definition between JCR 1.0 and JCR 2.0... but maybe not fully thought through when it comes to backwards compatibility and I am sure that we would have changed it when moving to Jackrabbit 2.x if that had worked. Kind regards Angela On 20/07/16 12:53, "Chetan Mehrotra" <[email protected]> wrote: >On Wed, Jul 20, 2016 at 4:04 PM, Marcel Reutegger <[email protected]> >wrote: >> Maybe we would keep the jcr:uuid property on the referenceable node and >>add >> the mixin? > >What if we do not add any mixin and just have jcr:uuid property >present. The node would anyway be indexed so search would still work. >Not sure if API semantics require that nodes lookedup by UUID have to >be referenceable. > >For now I think oak:Resource is safest way. But just exploring other >options if possible! > > >Chetan Mehrotra
