jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: [jr3] Tree model
Date Mon, 05 Mar 2012 10:25:28 GMT
Hi,

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

I agree. I guess the reason why we didn't implement this yet is because
it's a bit complicated, and we didn't know so far whether it's really
important.

What about I build a Jackrabbit 2 -> MicroKernel import tool (we probably
anyway need a fast import tool, to convert existing repositories), and
then test iterating over all child nodes using some test data (for example
a Day CQ installation), using a small threshold for large child node
lists. Additional realistic data sets are welcome of course.

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

I guess we will end up with b) at some point, but a) is fine for me.

>Fair point. I think the best alternatives here are the ones we're
>already using in jr2: PropertyState, NodeState and ChildNodeEntry.

Sounds good to me. Not perfect I agree...

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

Yes, makes sense. I shouldn't have used "Data" really.

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

If we want to use distinct interfaces for read-only and writable nodes,
what about "ImmutableNode" and "MutableNode extends ImmutableNode". If we
need a common interface at all, it wouldn't be used in the code a lot, so
the name of that one wouldn't matter that much.

Regards,
Thomas


Mime
View raw message