jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3] Tree model
Date Fri, 02 Mar 2012 17:22:44 GMT


On 2.3.12 16:17, Stefan Guggisberg wrote:
>> >
>> >  * The data model specifies that a node contains an "an array of
>> >  (child) node objects" and seems to imply that child nodes are always
>> >  orderable. This is a major design constraint for the underlying
>> >  storage model that doesn't seem necessary (a higher-level component
>> >  could store ordering information explicitly) or desirable (see past
>> >  discussions on this). To avoid this I think child nodes should be
>> >  treated as an unordered set of name/node mappings.
> i don't think that it is a major design constraint in general.
> since in a jcr repository a lot of content is expected to be
> ordered (->  nt:unstructured) we should IMO support this in the mk
> and don't delegate this to the upper layer.
>
> i agree that very 'flat' nodes are a special case.
> how about stating something along the line of:
>
> child nodes are an orderable (implying 'ordered' of course) set
> of name/node mappings. however, if the size of the set
> exceeds a certain (discoverable?) trheshold, it might just
> ordered, but not orderable.
>

I thinks that this is better tackled the other way around: store order 
explicitly as Jukka proposed. This will basically have the same 
observable effect as you describe but OTOH free the implementation from 
the constraint of having to maintain the order. Furthermore it leaves 
the decision for the threshold to the upper layers which can decide 
individually what's good for them.

Michael

Mime
View raw message