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<[email protected]> 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
