Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <3613807.1155284774811.JavaMail.jira@brutus>
Date: Fri, 11 Aug 2006 01:26:14 -0700 (PDT)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-542) Allow the removal of an item even if
 its schema has changed
In-Reply-To: <3333338.1155257234827.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/JCR-542?page=comments#action_12427468 ] 
            
Stefan Guggisberg commented on JCR-542:
---------------------------------------

your problem is inconistent repsoitory content. i assume you did the schema changes manually, i.e. by editing the internal custom_nodetypes.xml file. i have repeatedly pointed out that this is not recommended because it may lead to inconsistent/corrupt repository content (just like you've experienced). the proper way to do schema changes is by calling NodeTypeRegistry.reregisterNodeType().  support for trivial schema changes (those that do not affect the consistency of existing content) is already implemented.  Jira issue JCR-322 addresses non-trivial schema changes.

> Allow the removal of an item even if its schema has changed
> -----------------------------------------------------------
>
>                 Key: JCR-542
>                 URL: http://issues.apache.org/jira/browse/JCR-542
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.0.1
>            Reporter: Florent Guillaume
>            Priority: Minor
>
> During schema migrations, it is often the case that an item definition changes. For instance, a property may move from type Long to type String.
> However when jackrabbit is restarted, it's impossible to remove any node having "old" properties:
> javax.jcr.nodetype.ConstraintViolationException: no matching property definition found for {}myprop
>         at org.apache.jackrabbit.core.nodetype.EffectiveNodeType.getApplicablePropertyDef(EffectiveNodeType.java:797)
>         at org.apache.jackrabbit.core.NodeImpl.getApplicablePropertyDefinition(NodeImpl.java:913)
>         at org.apache.jackrabbit.core.ItemManager.getDefinition(ItemManager.java:161)
>         at org.apache.jackrabbit.core.ItemManager.createPropertyInstance(ItemManager.java:522)
>         at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:477)
>         at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:320)
>         at org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:674)
>         at org.apache.jackrabbit.core.NodeImpl.removeChildNode(NodeImpl.java:623)
>         at org.apache.jackrabbit.core.ItemImpl.internalRemove(ItemImpl.java:848)
>         at org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:1034)
> I don't understand enough of the internals to know if it's easy, but could something be made more lenient to allow such removals?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira