/content/mysite/en) it'll be much slower than well written JCR query.
Purpose of the SlingQuery is to provide a convenient way to traverse resource tree. All SlingQuery operations are eventually transformed into a series of
getParent() operations .
As a rule of thumb - if you have a complex Java loop reading resource children or parents and processing them somehow, rewritting it to SlingQuery will be a good choice. If you have a recursive method trying to get some resource ancestor, using SlingQuery will be a good choice. On the other hand, if you have a large resource subtree and want to find all
cq:Pages, using SlingQuery is a bad choice.
|You have a complex logic using Sling Resource API||Yes!|
|You want to find resource ancestor||Yes!|
|You want to find all descendants with given attribute||Yes!|
|You want to find all descendants of given type||Yes!|
|You'd like to get ordered results||Yes!|
 - Actually, the
find() operation uses QUERY strategy by default, which means that the selector string is transformed to a SQL2 query. However, the transformation process is very naïve and simply skips all conditions that can't be easily transformed to SQL2 (eg. selector
[jcr:content/jcr:title=some title] won't be transformed as it contains some subresource reference). The result of this query is then filtere manually. See searchStrategy for more details.
Since this Feature is not available OOTB, you can download bundle from Bundle
Add following Maven dependency to your pom.xml: