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.
Michael
