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 Tue, 19 Feb 2013 13:41:14 GMT

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

Alex Parvulescu commented on JCR-3524:

forgot to list the tests:

 - SetPropertyConstraintViolationExceptionTest#testReferenceProperty
 - SetValueConstraintViolationExceptionTest#testReferenceProperty
 - SetValueConstraintViolationExceptionTest#testMultipleReferenceProperty
> 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
> 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