jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [jr3] Orderable child nodes: required (to be the default)?
Date Mon, 23 Jan 2012 10:43:30 GMT

Am 23.01.2012 um 10:43 schrieb Jukka Zitting:

> Hi,
> On Sat, Jan 21, 2012 at 11:37 PM, Tobias Bocanegra <tripod@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.


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

View raw message