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
