The last time I heard of a discussion along these lines, such an API was
frowned upon a bit because it is susceptible to having a very large amount
of returned data and thus being having a strong potential for causing
disruption for other uses, particularly if the entire returned result has
to be as of a single moment in transactional time.

This same argument can be applied to getting all of the first level
children of a single znode, but getting an atomic view of that is
considerably more important since many algorithms depend on seeing a
consistent view of the children of a node.



On Mon, Oct 9, 2023 at 9:25 PM Enrico Olivelli <eolive...@gmail.com> wrote:

> Hello,
> today I was discussing with a friend from the Solr community, they
> would need to read a whole subtree in one shot.
>
> I can't remember if we have something like that, do you have any pointers ?
>
> Cheers
> Enrico
>

Reply via email to