Sling Query is not meant to replace JCR queries (XPath, JCR-SQL, JCR-SQL2). It doesn't use indexes and generally in queries traversing large subtrees (like
/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.