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 Mon, 05 Mar 2012 10:48:20 GMT

On 5.3.12 9:45, Marcel Reutegger 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.
> I agree with Michael on where to maintain the order of child nodes
> when needed. However, I don't agree that there should be a threshold
> where the behavior will flip. Even if it is documented, people will
> probably rely on the initial behavior when they test their application
> with a small set of content and then find out their application breaks
> as more content is added. I think it is better to have consistent
> behavior.

Agreed. Emphasis was not on the threshold. Rather I meant that upper 
layers are free to choose any implementation that they see fit.


View raw message