On Sat, Jan 21, 2012 at 11:37 PM, Tobias Bocanegra<tri...@adobe.com> wrote:
so for large childnode lists, a stable but uncontrollable order
would be ok, although violating the spec?
I wouldn't violate the spec for this. If you have an orderable node
(like nt:unstructured), then the repository should keep track of the
order of child nodes regardless of how many they are. IMHO it's OK for
the repository *not* to scale up or perform well if someone dumps a
million child nodes to an orderable parent.
However, it would be great if we could implement efficient storage for
nodes with lots (i.e. millions) of unorderable children. In such a
case I'd say we can expect the client to explicitly use a parent node
with a custom node type that doesn't require orderability.
I am not sure, whether this proposal does not open a can of worms: Consider
using a node for child nodes whose retrieval should be ordered by insertion
order. This is currently guaranteed by switching on ordered child nodes on the
parent node, right ?
So, applications using this will always use ordered nodes and thus suffer from
performance again ... not good.
Well, there is no free lunch...
If we want to go 'big data' and distributed, we will have to make trade
offs. What we need to do IMO is to carefully identify the areas where we
can/want to trade off and make sure these are well understood.
Michael
