jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Tree model
Date Mon, 05 Mar 2012 10:00:41 GMT
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.

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