jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3] Orderable child nodes: required (to be the default)?
Date Mon, 23 Jan 2012 11:59:11 GMT
>> 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.

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

Mime
View raw message