jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Tree model
Date Mon, 05 Mar 2012 13:10:19 GMT

On Mon, Mar 5, 2012 at 1:36 PM, Marcel Reutegger <mreutegg@adobe.com> wrote:
>>     int getChildNodeCount();
> this doesn't work well when you have concurrent child node
> operations. e.g. one session adds a child node while another
> session removes the child nodes.

We're talking about an immutable state here, so the child node count
never changes for a given NodeState instance.

> IMO it would be better if the number of child nodes is calculated
> by the caller. why do we have the method anyway? ;)

The caller may well want to adapt it's functionality depending on
whether a node has 10 or 10M child nodes.

>>     Iterable<ChildNodeEntry> getChildNodeEntries(int offset, int length);
> doesn't this imply that the implementation will keep the child
> nodes in a list?

Any implementation that supports orderable child nodes is necessarily
some form of a list.

The only extra bit here is that I'm expecting the implementation to be
able to use a numeric index instead of some other pointer to indicate
the starting point. That should be easily doable with most models of
persistence. Also, the current MicroKernel interface assumes that the
underlying storage model is able to use numeric indices.


Jukka Zitting

View raw message