jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-270) Enforce uniqueness of jcr:uuid
Date Wed, 22 Aug 2012 08:57:41 GMT

    [ 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

        

Mime
View raw message