You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Jörg Hoh <jh...@googlemail.com> on 2017/09/06 20:27:49 UTC

SegmentNodeStore documentation

Hi Oak-Devs

I wonder about the documentation at
http://jackrabbit.apache.org/oak/docs/nodestore/segmentmk.html

In the section "Node records" it's stated:

"A node that contains more than N properties or M child nodes (exact size
TBD, M ~ 1k) is stored differently, using map records for the properties
and child nodes. This way a node can become arbitrarily large and still
remain reasonably efficient to access and modify. The main downside of this
alternative storage layout is that the ordering of child nodes is lost."


Is this a valid statement for Oak 1.x? I would be really surprised, that
starting at an arbitrary number of childness the ordering of childnode gets
lost (for performance reasons). Can someone confirm?

Thanks!

-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh

Re: SegmentNodeStore documentation

Posted by Jörg Hoh <jh...@googlemail.com>.
Hi,

2017-09-06 23:14 GMT+02:00 Michael Dürig <md...@apache.org>:

>
>
> On 06.09.17 22:27, Jörg Hoh wrote:
>
>> Hi Oak-Devs
>>
>> I wonder about the documentation at
>> http://jackrabbit.apache.org/oak/docs/nodestore/segmentmk.html
>>
>> In the section "Node records" it's stated:
>> [...]
>>
>
> Yes this is a valid statement for all versions of Oak since 1.0.
>
> I think you are misreading it a bit. The sentence "The main downside of
> this alternative storage layout is that the ordering of child nodes is
> lost." does not imply there is some ordering and after a number of nodes
> there in no more ordering. It means that the implementation does not make
> any guarantee regarding the ordering.
>
> Moreover this statement is in no way related to orderability of child
> nodes in JCR. This is a different concern implemented in a layer higher up
> the stack


I think, that this is the misleading part. I would be great if it could be
added, because lot of people are reading these pages with a JCR semantic in
mind.  Thanks for the clarification, I will raise a ticket and ask for an
improvement.

Jörg


-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh

Re: SegmentNodeStore documentation

Posted by Michael Dürig <md...@apache.org>.

On 06.09.17 22:27, Jörg Hoh wrote:
> Hi Oak-Devs
> 
> I wonder about the documentation at
> http://jackrabbit.apache.org/oak/docs/nodestore/segmentmk.html
> 
> In the section "Node records" it's stated:
> 
> "A node that contains more than N properties or M child nodes (exact size
> TBD, M ~ 1k) is stored differently, using map records for the properties
> and child nodes. This way a node can become arbitrarily large and still
> remain reasonably efficient to access and modify. The main downside of this
> alternative storage layout is that the ordering of child nodes is lost."
> 
> 
> Is this a valid statement for Oak 1.x? I would be really surprised, that
> starting at an arbitrary number of childness the ordering of childnode gets
> lost (for performance reasons). Can someone confirm?

Yes this is a valid statement for all versions of Oak since 1.0.

I think you are misreading it a bit. The sentence "The main downside of 
this alternative storage layout is that the ordering of child nodes is 
lost." does not imply there is some ordering and after a number of nodes 
there in no more ordering. It means that the implementation does not 
make any guarantee regarding the ordering.

Moreover this statement is in no way related to orderability of child 
nodes in JCR. This is a different concern implemented in a layer higher 
up the stack.

Michael