[
https://issues.apache.org/jira/browse/JCR-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680824#action_12680824
]
Stefan Guggisberg commented on JCR-2011:
----------------------------------------
i can see your use case. however, setPrimaryType and add/removeMixin do behave
differently because the former is an atomic operation whereas the latter isn't.
mimicing the behavior of setPrimaryType for changing the assigned mixins woud
require to defer the actual change to the save operation (as you correctly
mentionend). this OTOH would cause backwards compatibility issues because
the (transient) effect of an add/remove mixin would only be visible after a
save call. IMO that's not an option.
> This is not strictly a bug, as JSR-283 seems to leave the details of
> assigning node types (section 5.5) unspecified. However, it does say for
> Node.removeMixin(String) that "Both the semantic change in effective node
> type and the persistence of the
change to the jcr:mixinTypes property occur on save" and ideally we could
emulate the nice behaviour in NodeImpl.setPrimaryType(String) for mixin types.
the current implementation of add/remove mixin are IMO according to the spec.
'semantic change' refers to node types with special semantics (e.g.
mix:versionable). adding mix:versionable to a node does create the necessary
properties on the node. the node does become 'versionable' only after calling
save.
> Replacing mixin type doesn't preserve properties
> ------------------------------------------------
>
> Key: JCR-2011
> URL: https://issues.apache.org/jira/browse/JCR-2011
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Reporter: Charles Brooking
> Priority: Minor
>
> NodeImpl.setPrimaryType(String) attempts to "redefine" nodes and properties
> that were defined by the previous node type if they also appear in the new
> type. If there is no matching definition for a node/property in the new type
> - or value conversion for matched node/property fails - only then are
> children removed. For example, say I have a node "harry", with a primary type
> "Human" that defines a "bloodgroup" property. If I set the primary type to be
> an unrelated type "Animal" that has a similar "bloodgroup" property, then its
> property value will survive the call to setPrimaryType("Animal").
> The same is apparently not possible with mixins. NodeImpl.removeMixin(Name)
> immediately removes all children that were defined by the mixin (strictly,
> those that are not present in the effective node type resulting from the
> mixin being removed). In addition, NodeImpl.addMixin(Name) immediately throws
> a NodeTypeConflictException if you attempt to add a mixin defining an
> identically-named property prior to calling removeMixin. For example, say I
> have a node "matrix", with a mixin type "movie" that defines a "title"
> property. If I wish to replace the "movie" mixin on that node with another
> "jcr:title" mixin type, the existing "title" property will be deleted.
> This occurs regardless of the order in which removeMixin and addMixin are
> called, and without session.save() being called between them. One option for
> coding this is to defer validation (and possible node/property removal) until
> session.save() is called.
> This is not strictly a bug, as JSR-283 seems to leave the details of
> assigning node types (section 5.5) unspecified. However, it does say for
> Node.removeMixin(String) that "Both the semantic change in effective node
> type and the persistence of the
> change to the jcr:mixinTypes property occur on save" and ideally we could
> emulate the nice behaviour in NodeImpl.setPrimaryType(String) for mixin types.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
