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] Tree model
Date Mon, 05 Mar 2012 11:18:38 GMT


On 5.3.12 10:00, Jukka Zitting wrote:
> Hi,
>
> Sounds like we're converging towards consensus here. Great!
>
> On Mon, Mar 5, 2012 at 10:20 AM, Thomas Mueller<mueller@adobe.com>  wrote:
>> Maybe we should go for "always orderable" child node lists, simply to
>> avoid confusion. Even if it's a bit slower.
>
> I'm OK with that. Just note that this may well have unexpectedly hard
> performance consequences for the flat hierarchy use case.

As I mentioned earlier [1], instead of trading support for large child 
node lists against support for ordering there might be another dimension 
along we could tune that trade-off: assuming the Microkernel supports a 
stable iteration order (better even insertion order), we could as well 
implement re-ordering by persisting the re-order operations. When 
iterating over child nodes, such persisted re-order operations would 
have to be applied on the fly. I think such an approach would be 
relatively easy to implement and the related complexity would not 
pervade other areas of the code. Finally the approach would scale 
linearly with the number of re-order operations which should be 
acceptable and easy to communicate to end users.

Michael

[1] http://markmail.org/message/u7jpuztgb7utrznz


>
> It would be great if someone could try benchmarking the performance of
> iterating over and updating a large node with say 1M or 10M child node
> entries (using the existing prototype code designed for this), both
> with and without explicit ordering. Such data would make reaching a
> conclusion here much easier than with the current vague assumptions
> we're making.
>
>>> Note that if we do mandate orderability on child nodes, supporting
>>> SNSs on the MK level becomes much less of an issue as the internal
>>> storage model needs to be (at least some form of) a list instead of
>>> just a map.
>>
>> I think SNS would still be a big problem :-)
>
> Yes, they are in any case. :-) The main question here is, which one is
> easiest: a) not support SNS at all, b) support SNS above the MK level,
> or c) support SNS below the MK level. Personally I'd be happy with a),
> but I suppose we have use cases where SNS support is needed.
>
>> So in your model a "tree" is a node? A "leaf" is a property? What is a
>> branch, a "child node"?
>
> Yes. Yes. Child node entry, i.e. a named reference to a subtree.
>
>> I prefer using the same terms for the same things consistently. A node
>> shouldn't sometimes be called node and sometimes tree. I understand we
>> have a naming conflict here with javax.jcr.Node and Property, but what
>> about name combinations:
>
> Fair point. I think the best alternatives here are the ones we're
> already using in jr2: PropertyState, NodeState and ChildNodeEntry.
> Like Dominique, I tend to associate ...Data names with dumb bean
> objects, whereas ...State has the nice suggestion of "this is a
> specific (immutable) state of an item, a different state will be
> represented by another state instance". Unfortunately jr2 treats
> ...State more like "this is the current state of an item, updated
> automatically on changes", which might be a bit confusing for jr3.
>
> BR,
>
> Jukka Zitting

Mime
View raw message