jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-853) [PATCH] Jackrabbit disallows some nodetype changes which are in fact safe.
Date Thu, 19 Apr 2007 09:49:15 GMT

    [ https://issues.apache.org/jira/browse/JCR-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489982
] 

Stefan Guggisberg commented on JCR-853:
---------------------------------------

i agree on the issue.

the proposed patch unfortunately breaks the semantics of the buildPropDefDiffs method.

the changes don't account for node types having mutliple property definitions sharing the
name.

e.g. 

[myapp:record]
  - * (myapp:data) multiple
  - * (myapp:data)


> [PATCH] Jackrabbit disallows some nodetype changes which are in fact safe.
> --------------------------------------------------------------------------
>
>                 Key: JCR-853
>                 URL: https://issues.apache.org/jira/browse/JCR-853
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: nodetype
>    Affects Versions: 1.2.1
>            Reporter: Simon Edwards
>         Assigned To: Stefan Guggisberg
>            Priority: Minor
>         Attachments: NodeTypeDefDiff_JCR-853.diff
>
>
> When reregistering nodetypes using org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.reregisterNodeType(),
Jackrabbit uses the NodeTypeDefDiff class to compare the old nodetype definitions with the
new definitions to determine if the nodetype changes can be permitted. Changing a node property
from not multiple to multiple is safe and should be allowed, but there is a bug in NodeTypeDefDiff.java
which prevents this change from being permitted.
> The NodeTypeDefDiff..buildPropDefDiffs() tries to compare the old and new version of
each property definition. Around line 260, it tries to pull the new definition of a property
out of a map using the PropDefId object from the old definition as a key. The problem is that
this key is not only built up from the name of the property, but also from its attributes
(e.g. multiple, type, constraints etc). This means that if the property definition changes,
then the new property definition will have a different PropDefId than the old version and
hence will not be found in the map. The code then treats the missing property definition as
being a major change that can't be permitted.
> see patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message