Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Wed, 20 Feb 2013 12:53:12 +0000 (UTC)
From: "Alex Parvulescu (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12632982.1361281122048.310283.1361364792770@arcas>
In-Reply-To: <JIRA.12632982.1361281122048@arcas>
References: <JIRA.12632982.1361281122048@arcas>
Subject: [jira] [Commented] (JCR-3524) Node type selection for reference
 constraint is not optimal
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Alex Parvulescu commented on JCR-3524:
--------------------------------------

bq. i would rather define one or a set of custom test node type(s) that provide the functionality required for the tests. 

I think that is a big change for the test, my proposal was to just tweak the node type selection a bit.

The way the test is built is perfectly fine in my view, it finds a "good" node type (this is already defined/hardcoded via the config), then by iterating through existing node types finds a "bad" node type. No need to hardcode anything really.
The problem is when the "bad" node type has constraints on the node structure (expects some specific child nodes to be present on save). 
My proposed patch is to simply pick a better "bad" node type for the test.
                
> Node type selection for reference constraint is not optimal
> -----------------------------------------------------------
>
>                 Key: JCR-3524
>                 URL: https://issues.apache.org/jira/browse/JCR-3524
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr-tests
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>            Priority: Minor
>         Attachments: JCR-3524.patch
>
>
> I've found 3 unit test that randomly choose a node type for a node that is supposed to break a reference constraint.
> The problem with the way the node type is selected is that the code could choose one that has itself some constraints (like nt:file for example). This can make the test pass for the wrong reason.
> Unfortunately having one exception for both test and failure to create a proper node structure (like in the case of an empty nt:file node) doesn't help with understanding what is happening, either.
> This came up in OAK-624, where the aforementioned behavior changed and the test started failing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira