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
