jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Parvulescu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3524) Node type selection for reference constraint is not optimal
Date Wed, 20 Feb 2013 12:53:12 GMT

    [ 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

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

View raw message