Query Builder

Search is always the backbone of many functionalities in an AEM application . It becomes quite critical in Business scenarios to implement the most Optimized Query which fetches the best possible result. To perform search in AEM , Query Builder is highly recommended over simple SQL / XPATH query statements. The Query Builder , if used correctly, will solve all your query implementations and would be a handy way to Optimize your queries for better performance of the page. Through this Blogpost , I would explain the basics of Query builder and then would go to advanced concepts , focusing at each point how you may create any search scenario to Query Builder Predicate form. I hope this post will solve all your Search performances related hurdles in AEM.

What is Query Builder?

Query Builder is an APIwhich can be used to create Search queries in JAVA content repository. It is extensible tool by which you may add/remove various predicates in a query using this API. The best way to create predicates is using the Query Builder Debugging Tool : /libs/cq/search/content/querydebug.html . Try to implement your Business use case in the Predicate form using this debugger, Optimize the query and then implement it in the code.

Anatomy of a Query:

The query description is a set of predicates which evaluate to an XPATH /JCR query in the backend. To understand more check the screenshot below:

Every Predicate is evaluated using a Predicate Evaluator. There are some in-built predicates in AEM. And you may always customize the predicates and use it as per your Business need. I will go in more details for creating new predicates later.

Implementation :

You may refer to the links : Adobe Doc or Use the API to implement your queries using a Query Builder.

Standard Predicates : Deep understanding of predicates is necessary if you want to Optimize any if your Search Query.

path : This is used to search under a particular hierarchy only.

path.self=true : If true searches the subtree including the main node given in path, if false searches the subtree only.

path.exact=true : If true exact path is matched, if false all descendants are included.

path.flat=true : If true searches only the direct children .

type: It is used for searching for a particular nodetype only.

property: This is used to search for a specific property only.

property.value : the property value to search . Mutilple values of a particular property could be given using property.N_value=X , where N is number from 1 to N.

property.depth : The number of additional levels to search under a node. eg. if property.depth=2 then the property is searched under

property.and : If multiple properties are present , by default an OR operator is applied. If you want an AND , you may use property.and=true

property.operation : “equals” for exact match (default), “unequals” for unequality comparison, “like” for using the jcr:like xpath function , “not” for no match , (value param will be ignored) or “exists” for existence match .(value can be true – property must exist).

fulltext.relPath : the relative path to search in (eg. property or subnode) eg. fulltext.relPath=jcr:content or fulltext.relPath=jcr:content/@cq:tags

daterange : This predicate is used to search a date property range.

daterange.property : Specify a property which is searched.

daterange.lowerBound : Fix a lower bound eg. 2010-07-25

daterange.lowerOperation : “>” (default) or “>=”

daterange.upperBound: Fix a lower bound eg. 2013-07-26

daterange.upperOperation: “<” (default) or “<=”

relativedaterange: It is an extension of daterange which uses relative offsets to server time. It also supports 1s 2m 3h 4d 5w 6M 7y

relativedaterange.lowerBound : Lower bound offset, default=0

relativedaterange.upperBound : Upper bound Offset .

nodename: This is used to search exact nodenames for the result set. It allows few wildcards like: nodename=text* will search for any character or no character after text. nodename=text? will search for any character after text.

tagid: This predicate is used to search for a particular tag on a page. You may specify the exact tagid of a tag in this predicate

tagid.property: this may be used to specify the path of node where tags are stored.

group: This predicate is used to create logical conditions in your query. You can create complex conditions using OR & AND operators in different groups. e.g:

p.nodedepth: Use this when you need properties of a node and its child nodes in the same search result. Use this with p.hits=full Example

p.facets=true : This will be used to Search Facets based search for the assigned Query. If you want to calculate the count of tags which are present in your search result or you want to know how many templates for a particular page are there etc, you may go with Facets based search . Example

In most of the cases the standard predicates would solve your purpose of creating Queries for any business scenario. However sometimes we may need to Create Custom Predicates. I will tell you more about this later.

Custom Predicate Evaluators:

Broadly there are 2 kinds of Predicate Evaluators which can be used to create new predicates as per Business need.

XPath Predicate:This is used to create a Backend XPATH Query using the new custom predicates which can be defined as per need. Many of the inbuilt CQ predicates are XPATH predicates. Notice that in XPATH Predicate Evaluator the overriden method canXpath() should return true while canFilter() should return false. Use the below code snippet to create Custom Predicates :

Filter Predicate :This predicate is used whenever you want to Filter out some results which are not needed in the end Search Result. Notice that in Filter Predicate Evaluator the overriden method canXpath() should return false while canFilter() should return true.

Improving Search Performance

By far this is the most important question of any project , and I am telling you its not that difficult. Just a few steps to follow and few things to be aware of and you will be able to optimize the Query to its utmost performance level.

Build a Query with the maximum predicates possible for that node , as long as you reduce the Search pool. e.g. If you are searching for a component node with property= sling:resourceType , add nodename predicate too to make the search quicker.

Keep in consideration what you need in Search Results. If you need cq:Page , it would be bad idea to search for type=nt:unstructured.

Always check whether the results are upto the Business need, after the grouping and logic you apply in your Predicate based search.

Try to reduce the processing of the Search results as much as possible. e.g. Its better to use facets then to process the results again

Go for Custom Predicate Evaluators if you are not able to define your complex query using existing ones or if you think you may simplify the query to a greater level using custom predicates.

Depending on your application logic, if the result set is more, dont load all the results in DOM and go via partial load using p.limit and p.offset parameters.

If the search is for anonymous users and no permission sensitive search is needed, use p.guesstotal=true . The purpose of the p.guessTotal parameter is to return the appropiate number of results that can be shown by combining the minimum viable p.offset and p.limit values. Basically it stops the permission check for that session on each node of the result set and makes the Search query performance better.

Related posts

Post navigation

25 thoughts on “Query Builder”

I’m not an AEM developer but have been asked to implement search in our AEM website which requires searching multiple paths so I cannot use the basic Search component. Adobe support has told me that I need to use the Query Builder API to do this. I have been unable to find any examples of how to implement it in a web page (form) or component. My question is how do I implement this in a search form on a web page. Any direction you can give is appreciated.

Have you tried the “not” operator in Property predicate ? “not” for no match , (value param will be ignored)
Or if the appropriate predicate is not there you can always go back to SQL Query (eg ):
select * from [nt:base] as t where name(t) = ‘rep:policy’ AND t.[jcr:primaryType] NOT LIKE ‘rep:ACL’

Thank you for the very speedy response. The “not” operator is the opposite of the “exists” operator and tests for the absence of a property. I have tried all other combinations but can’t seem to arrive at the equivalent of a NOT LIKE .

With SQL can you point me in the direction of a REST interface, similar to Querybuilder.json that takes a URL query, in SQL format, and returns the results in JSON?

Hello Hashim,
Thanks for your tutorial.It is really very helpful for beginner.
I have one doubt.you have mentioned that “If multiple properties are present , by default an OR operator is applied. If you want an AND , you may use property.and=true”.But i can see that if multiple properties are present AND operator is bydefault applied.Please correct me if i m wrong.

Hi,
I dont think so there is a limit to that. But why do you need to do so ? What is the use case for it ? Fulltext search is generally heavy and doing so in multiple paths would make it slow .
Regards
Hashim

Hi Prahlad,
It depends on the Query which you are making. Generally pages with Search/ Dynamic Content aren’t cached much on Dispatchers, so they are bound to hit Publishers. You can optimize the query as much as possible, provide proper indexing , introduce pagination to reduce the impact.

Blog Hits

Author

I am Hashim Khan, a certified AEM developer ,a JAVA enthusiast, an expert Consultant and a Web Development Solution Provider . If you have a project that needs some AEM expertise then that’s where I come in! Since the start of my career I have been working on AEM and related technologies & since Feb 2015 , through this blog I am trying to share my AEM knowledge and give back to the AEM community.