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

Marcel Reutegger commented on JCR-741:
--------------------------------------

> Not convinced. If the node type allows multiple property definitions here, 
> obtaining the right one from the
> store doesn't seem to be any harder than selecting one of the ones supplied 
> by the caller.

my point is to possibly avoid a call (by an spi implementation) to the store 
and give an spi implementation the opportunity to implement the method as an 
entirely local call. Would this work in your case, or would you still have to 
ask the store to pick the right definition?

> Anyway; if we do that, do we still need 
> RepositoryService.getPropertyDefinition? Right now it's not used
> by JCR2SPI which makes me a bit nervous :-).

IMO we should remove the method RepositoryService.getPropertyDefinition() 
anyway. It does not scale well and in almost all cases it can be infered from 
the node type definition which property definition applies to a certain 
property. I think the same also applies to child node definitions (jcr2spi only 
uses the method to get the node definition for the root node).

Using the node type definition and its item definitions require much lesser 
calls to the SPI than using getPropertyDefinition() and getNodeDefinition(). 
So, I think jcr2spi does it the right way, even though it doesn't use 
getPropertyDefinition().

> Handling of multiple residual prop defs in EffectiveNodeTypeImpl
> ----------------------------------------------------------------
>
>                 Key: JCR-741
>                 URL: https://issues.apache.org/jira/browse/JCR-741
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: SPI
>            Reporter: Julian Reschke
>         Assigned To: Julian Reschke
>            Priority: Minor
>
> org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently 
> rejects multiple residual property definitions, if they do not differ in 
> getMultiple(). In fact, it should accept all combinations, so differing 
> values for getOnParentVersionAction and other aspects should be accepted as 
> well.
> See JSR 170, 6.7.8:
> "For purposes of the above, the notion of two definitions having the same 
> name does not apply to two residual definitions. Two (or more) residual 
> property or child node definitions with differing subattributes must be 
> permitted to co-exist in the same effective node type. They are interpreted 
> as disjunctive (ORed) options."

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to