[dna-issues] [JBoss JIRA] Updated: (DNA-439) JcrNode.setProperty(String, String|Value, int) Doe sNot Always Throw ConstraintViolationException Correctly

[Brian Carothers (JIRA)]

     [ https://jira.jboss.org/jira/browse/DNA-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-439:
--------------------------------

    Attachment: DNA-439.patch


Attached patch that adds a custom type required for the test and modifies the repository stub properties to utilize the new type.

More importantly, the patch also modifies the behavior of RepositoryNodeTypeManager.findBestPropertyDefinition to change the order of importance of the three dimensions of the property (name, type, cardinality).  Previously, the RTNM.fBPD method would first try to match on name, type, and cardinality.  If that did not work, it would try to match on name and type.  If that did not work, it would try to map on name and any type that could be converted to the correct type.  If all of those failed, it would try again searching for residual properties.  This creates a problem in that a node type may declare a named property (e.g., "prop1" with type DATE) and a residual property (e.g., with type BOOLEAN).  The prior method would return the residual property as a best match for property "prop1" with type BOOLEAN.  In our type system (which, admittedly, was almost entirely written after this method was last modified), this should return no match to avoid violating the node type's contract for the type of "prop1".

The modified version first tries to match on name.  If any definitions are found for the name, the method tries to match on exact type and cardinality.  Failing that, it tries to match the named definition on cardinality and a convertible type.  Failing that, it (optionally, depending on the arguments) attempts to match on type without regards to cardinality.  Finally, it attempts to match on name and the convertible type.  If there is no match for the requested type on the named property, it returns no match instead of proceeding on to try to match a residual definition.

This is a pretty key conceptual change to the way that the method works, although it is consistent with out typing rules, so I'm going to leave this patch out there for a day or two for comment.


> JcrNode.setProperty(String, String|Value, int) Doe sNot Always Throw ConstraintViolationException Correctly
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-439
>                 URL: https://jira.jboss.org/jira/browse/DNA-439
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>            Priority: Minor
>             Fix For: 0.5
>
>         Attachments: DNA-439.patch
>
>
> The JR TCK test SetPropertyAssumeTypeTest has two test cases for Node.setProperty(String, String|Value, int) with invalid types.  Both are currently failing.

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