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 >