[jira] [Resolved] (OAK-270) Enforce uniqueness of jcr:uuid

["Michael Marth (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Marth resolved OAK-270.
-------------------------------

    Resolution: Fixed

> Enforce uniqueness of jcr:uuid
> ------------------------------
>
>                 Key: OAK-270
>                 URL: https://issues.apache.org/jira/browse/OAK-270
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: core, jcr, query
>            Reporter: angela
>             Fix For: 0.14
>
>
> we had a quick discussion yesterday regarding enforcing uniqueness
> of jcr:uuid and how we are want/can assert that. 
> in contrast to what was said yesterday in the meeting the jcr:uuid cannot
> be expected to be always a system generated random uuid. That's only true
> for those cases where a referenceable node is created using Node#addNode
> or Node#addMixin("mix:referenceable"). However, this is not the case when
> content is imported using Session#importXML or Workspace#importXML. in these
> situations the generation of the jcr:uuid is not governed by the system.
> exporting and re-importing items is very likely to produce uuid-collisions
> and we need to make sure we can verify and assert the uniqueness in these
> cases.
> from the current layout i think that a ValidatorProvider present during
> commit validation would be the right place for such an assertion. in order
> to verify the feasibility of that i approach i added a UUIDValidator to
> the oak/identifier package some days ago (validation not yet implemented).
> if we find out that this is not suitable or reliable we probably have to
> look for a solution closer to the mk.
> in any case (and irrespective of the final solution) we should make sure
> we understand the (potential) limitation of the uuid-uniqueness in a
> clustered environment, make sure our implementation gracefully deals with
> potential violations and have limitations documented.
> maybe it was also wise discussion under which circumstances such 
> inconsistencies could be really harmful and where it might be acceptable.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)