Sling Query vs JCR




SlingQuery is a Sling resource tree traversal tool inspired by the jQuery JavaScript API. More details can be found at Apache Sling :: Sling Query

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 / or /content or /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 listChildren() and getParent() operations [1].

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.

Description JCR query SlingQuery
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!

[1] - 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: