jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: same name sibling issuesq
Date Sun, 27 Feb 2011 17:30:20 GMT
On Sat, Feb 26, 2011 at 10:29 PM, ChadDavis <chadmichaeldavis@gmail.com> wrote:
>> Here's my node types:
>> // The namespace declaration
>> <me = 'http://me.com'>
>> //my node types
>> [me:document] > nt:hierarchyNode, nt:unstructured, mix:versionable,
>> mix:lockable
>>   - me:docType (STRING)
>> [me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
>> Oddly enough, when I try to move a node ( me:folder ) to a location that
>> would cause a same name sibling conflict, it almost always rejects me with
>> an ItemExistsException.  However, a couple of times we've been able to
>> witness behavour where the session.move allows the same name sibling to be
>> created.  Interestingly, we do a parallel move on a second workspace
>> directly after this and that second workspace move tossed the
>> ItemExistsException even when the first one didn't.  Note, all of the
>> "parent" nodes in these moves are me:folder types.
>> When I started to review this issue, I noticed that nt:unstructured allows
>> SNS, and my node types all extend nt:unstructured.  To me not yet fully
>> matured understanding of defining node types, this leads me to believe that
>> my node types SHOULD allow SNS.
>> So, two questions persist:
>> 1) Do these node type definitions allow for SNS?  ( SNS of type me:document
>> or me:folder, and all under a parent of me:folder )
>> 2) Does my me:folder definition allow for SNS of me:document and me:folder?
> According to my reading of the specification, with regards to node type
> inheritance, I come up with the following effective node type definition for
> me:folder  (note: I'm omitting mixin related properties and properties in
> general as I'm only concerned with child node aspects here )
> [me:folder] > nt:folder, nt:unstructured, mix:referenceable, mix:lockable
>  + * (nt:hierarchyNode) VERSION                                   //from
> nt:folder
>  + * (nt:base) = nt:unstructured sns VERSION               // from
> nt:unstructured
> So, if I'm creating a me:folder under an me:folder, which child node rule
> applies.  The spec simply says that they are both "additive", because of
> being "residual".  My guess would be that the first rule applies, since my
> me:folder type is, from a type perspective, more specifically an instance of
> nt:hierarchyNode than an instance of nt:base.  But I am, admittedly, a bit
> lost here.

the following logic applies:

- find a matching 'named' child node definition (both name and required type
  constraints must be satisfied)
- if none exists, the first residual child node definition that satisfies
  the required type constraint is chosen. the order of evaluation is

see o.a.j.core.nodetype.EffectiveNodeType#getApplicableChildNodeDef
for the implementation.

while ranking the matching residual child node definitions by 'how well'
the required type constraint is satisfied would be theoretically possible
it's IMO not worth the extra overhead and negative performance impact.

WRT your use case i'd suggest to add residual property and child node
definitions to me:folder and remove the nt:unstructured supertype.



View raw message