[ 
https://issues.apache.org/jira/browse/OAK-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439367#comment-13439367
 ] 

Thomas Mueller commented on OAK-270:
------------------------------------

I agree (with both Angela and Michael). For a non-shareded repository, it 
should be (relatively) easy to guarantee uniqueness for UUID (and other) 
properties: the property index does support unique indexes already. MongoDB 
also supports unique indexes, but doesn't enforce uniqueness if it's shareded: 
http://www.mongodb.org/display/DOCS/Sharding+Limits#ShardingLimits-UniqueIndexesDOCS%3AIndexes%23UniqueIndexes
 
                
> Enforce uniqueness of jcr:uuid
> ------------------------------
>
>                 Key: OAK-270
>                 URL: https://issues.apache.org/jira/browse/OAK-270
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: core, jcr
>            Reporter: angela
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to