jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3] Tree model
Date Mon, 05 Mar 2012 11:07:45 GMT

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

Mime
View raw message