jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Brooking (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2011) Replacing mixin type doesn't preserve properties
Date Wed, 11 Mar 2009 11:05:50 GMT

    [ https://issues.apache.org/jira/browse/JCR-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680837#action_12680837

Charles Brooking commented on JCR-2011:

When you say "'semantic change' refers to node types with special semantics (e.g. mix:versionable)",
do you have a reference for this? I'd be interested in finding out what the spec actually

It says

    "the semantic change in effective node type
     and the persistence of the change to the jcr:mixinTypes property
     occur on save",

so surely this encompasses the change in effective node type! My interpretation of the phrase
"semantic change" is that it just distinguishes the meaningful effects of changing types from
the "literal change", which is the setting of the jcr:mixinTypes attribute.

So my (humble) interpretation is that if the change in effective node type should be persisted
on save, then this issue is valid. Say I remove one mixin type that includes a "foo" property
but add another mixin type including an identical "foo" property. If I do both of these things
before saving, then the "semantic change in effective node type" would be nil.

By the way, the spec for Node.setPrimaryType(String) also says: "Semantically, the new node
type may take effect immediately and must take effect on save. Whichever behavior is adopted
it must be the same as the behavior adopted for addMixin() and the behavior that occurs when
a node is first created." (section 5.5.3) This may mean that add/removeMixin should happen
on save (thus collectively being atomic like setPrimaryType), and maybe this is a bug rather
than improvement?

Some discussion on the list would be good, because I'm no JCR expert.

> 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.

View raw message