On 5.3.12 10:00, Jukka Zitting 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.
That doesn't work across the whole stack. The SPI based prototype [1]
was specifically tuned for allowing large child node lists. In the
process all support for ordering and ordered has been removed. The other
prototype [2] is not anywhere near where such tests could be done.
Maybe it is possible to run such tests on the Microkernel alone?
[1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/
[2] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/
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.
From personal communication with David I understand that we have
basically two use cases for SNS: Importing content (e.g. XML) and
creating nodes where the name doesn't matter. For both cases the
stringent requirements of the spec. - which basically requires SNS to be
'array addressable' - are not necessary. That is, for these cases SNS
could be implemented on top of the MK (i.e. option b)) through name
mangling. In that case we need to clarify whether we can do this within
the spec. or whether we need to work on it.
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.
What about HierarchyEntry? This term is currently used in the SPI stack
for similar purposes.
Michael
BR,
Jukka Zitting
