[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756700#comment-17756700
]
Julian Reschke commented on OAK-5229:
-------------------------------------
Just a thought after re-reading this...:
Whatever a client uses as sequence for updating a node type and the related
properties - if we fail early, it will be hard to use. If the client starts
adding properties before the new type is known, failing early will prevent it
to get to the poinzt when it can set the type.
> Using Node.setPrimaryType() should fail if non-matching childnodes
> ------------------------------------------------------------------
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.5.14
> Reporter: Tobias Bocanegra
> Priority: Critical
> Attachments: OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch, OAK-5229-v5.patch, OAK-5229-v6.patch,
> OAK-5229.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
