Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Date: Wed, 22 Aug 2012 23:44:38 +1100 (NCT)
From: "angela (JIRA)" <jira@apache.org>
To: oak-dev@jackrabbit.apache.org
Message-ID: <1277672580.39288.1345639478241.JavaMail.jiratomcat@arcas>
In-Reply-To: <1380008411.38818.1345623578048.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (OAK-270) Enforce uniqueness of jcr:uuid
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

angela commented on OAK-270:
----------------------------

for the record: currently the following code doesn't fail (nor would a similar
test setting an invalid jcr:uuid using the oak-api).

Session session = getAdminSession();
Node node = getNode("/foo");
node.addMixin("mix:referenceable");
Node node2 = node.addNode("foo2");
//node2.addMixin("mix:referenceable"); // optional. doesn't make a difference
node2.setProperty("jcr:uuid", node.getUUID());
session.save();
assertEquals(node.getUUID(), node2.getUUID());


> 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