Hi, Am 23.01.2012 um 10:43 schrieb Jukka Zitting:
> Hi, > > 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. > > I wouldn't even promise a stable iteration order for such cases. The > repository should be free to for example reorder the internal data > structure based on frequent access patterns. +1 Though paging to the list will then not be possible at all ! Wouldn't it be such, that "unordered" might mean "no defined but stable ordering" while ordered means "insertion order unless eplicitly changed" ? Both must really perform well or we get bad press again.... Regards Felix
