jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3] Tree model
Date Mon, 05 Mar 2012 13:38:36 GMT
On Mon, Mar 5, 2012 at 2:10 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> 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.
> BR,
> Jukka Zitting

View raw message