Hi Angela, I raised https://issues.apache.org/jira/browse/JCR-4759 and incorporated your feedback. Not sure if I can provide an implementation, not familiar enough with JR/Oak internals :-)
Jörg Am Fr., 14. Jan. 2022 um 11:45 Uhr schrieb Angela Schreiber <[email protected]>: > Hi Jörg > > Thanks a lot for reaching out. > > IMHO it makes sense to have this reported as feature request for > jackrabbit-api as there is no easy way to extend the existing JCR Node API > contract. > > There already exists a JackrabbitNode interface in oak-jackrabbit-api, > which we could use to add the new functionality. > > Would you be able to file a feature request in JIRA for this? > Obviously, a patch or PR would be welcome as well. > > Kind regards > Angela > > PS: i am wondering why the Pattern param would be named > 'notmatchingNodeNames'. it could be any kind of regex Pattern, couldn't it? > > PS2: for consistency we might also consider adding > JackrabbitNode.getChildren(Pattern pattern) alongside the new hasChildren > method. > > > ________________________________ > From: Jörg Hoh <[email protected]> > Sent: Friday, January 14, 2022 11:03 AM > To: [email protected] <[email protected]> > Subject: Check if a node has children NOT matching a pattern > > Hi, > > I have a requirement to check if a node has child nodes, which do not match > a certain pattern. This is definitely important, because > > node.hasChildren() > > will return true, if there is a "rep:policy" childnode below it. But this > node is an implementation detail of Oak, and it does not indicate that > there is a "real" child node below this node. The same happens with > "jcr:content" child nodes or other implementation specific nodes, which are > not considered as "independent child nodes" from an application point of > view. > The existing API allows only to check for the presence of child nodes > matching a certain glob (but not "not matching"), so it is of no help for > me. > > Right now it is implemented by iterating over the child nodes and returning > when the first child is detected which does not match the above criteria. > This works fine, but it is slow when the child node list is very long (e.g. > hundreds of nodes). Because then just getting the iterator can take > miliseconds, especially when the Oak repo is backed by Mongo. > On top i need to execute this operation quite a number of times within a > single request, so that getting these iterators can consume quite some > time, making my requests slower than they should be. > > I would like to have an API similar to the existing API, maybe looking like > this: > > node.hasChildren(Pattern notmatchingNodeNames) > > which allows me to provide a pattern to it. As soon as a childnode's name > is found not matching the pattern, the function returns true. This would > allow the implementation to iterate only over the minimal number of child > nodes, and I would expect it to be much faster than my existing > implementation for these larger folders. > > I know that the JCR API can hardly be extended by this, but having this in > a Util class would be fine as well. > > WDYT? > > Jörg > > -- > Cheers, > Jörg Hoh, > > https://cqdump.joerghoh.de > Twitter: @joerghoh > -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
