Author: Deepthi K

In our implementation we stumbled upon looking at what Coveo calls ‘aq’ bunch of times.  It is simply because of complexity involved on our implementation where we had to bend Coveo a little to achieve what the business needs are.

First up, let us first understand a little what is aq, dq and cq per Coveo.  They have beautiful documentation that iterates what these are.
https://developers.coveo.com/display/public/SearchREST/Query+Parameters

So, every time a query is fired by Coveo rendering because of coveo components you have on the page.   All these query parameters based on what is applicable is generated by Coveo, you can see this on Network tab in your browser when you take a look at Request headers and parameters.  If what coveo generates satisfies your business goals, you are good to call it a day.  But, what if it is not enough, you have to then modify and tweak to achieve what is needed.

When it comes to modifying the aq generated gracefully it becomes a challenge specifically if you are having issues with what Coveo does inherently while computing ‘aq’ for a rendering/request
One such case happened recently, where we needed a disjunction to be applied at a specific piece of generated ‘aq’.  We obviously could not get away with disjunctive expressions, I talked about this in my previous blog if you are curious.

https://deepthikatta.blogspot.com/2016/11/coveo-facet-slider-across-two-fields.html

The reason why this approach would not work in this case is because the way disjunctive expression works and is interpreted by Coveo in final query is aq OR dq which means in result set you will find all items that match your filters appended by Coveo in aq OR that match your expression that you added on dq.

But, what if you want this disjunction to applied only on a particular facet or custom advanced expression.  How can we do this? is it possible?

Like always, everything is possible. 🙂  In our case, it is little more complex because we also did not want what Coveo typically injects as a piece of aq on a Facet Slider for example because we would fall in to same problem which we began to solve if we don’t do this.   So, to achieve this, we did two steps.

1.  OR where you need – In event called buildingQuery, access the args and append the advanced expression that you need including a specific OR condition you care about.  Some thing like
Coveo.$(‘#@Model.Id’)
.on(“buildingQuery”, function(e, args) {
let mySlider = Coveo.$(‘#mySlider’)
if (mySlider != undefined) {
let optionsOfComponent = mySlider.coveo().getSliderBoundaryForQuery()
if (optionsOfComponent != undefined && optionsOfComponent[0] != undefined && optionsOfComponent[1] != undefined) {
let fieldOneQuery= ‘@(Model.ToCoveoFieldName(“field one”)) >=’ + optionsOfComponent[0] + ‘ AND @(Model.ToCoveoFieldName(“field one”)) <=’ + optionsOfComponent[1] let fieldtwoQuery= ‘@(Model.ToCoveoFieldName(“field two”)) >=’ + optionsOfComponent[0] + ‘ AND @(Model.ToCoveoFieldName(“field two”)) <=’ + optionsOfComponent[1]
args.queryBuilder.advancedExpression.add(‘((‘ + fieldOneQuery+ ‘) OR (‘ + fieldtwoQuery+ ‘))’) }}})

2. Remove the advanced expression added by Coveo –  Reverse engineered the string that Coveo would append on the facet slider per configuration and removed it using helper provided under Expression Builder.
https://developers.coveo.com/display/public/JsSearch/ExpressionBuilder

Some thing like –
.on(“doneBuildingQuery”, function(e, args)  {
//reverse engineer the value you would like to remove and ensure you have proper checks on coveo      components or facets before you access the values
let  expressionToRemove  = ‘@(Model.ToCoveoFieldName(“your slider         field”))==’+optionsOfComponent[0]+’..’+optionsOfComponent[1]
args.queryBuilder.advancedExpression.remove(expressionToRemove)})

That is it, we got what we needed when took a peek at Network tab and request parameters and the results matched to business goal.   One less thing to worry about.  We are launching this thing soon, totally psyched!

Recently, in one of our major Coveo renderings, there was a splurge of new requirements.  Well, no huge surprise there I think.  When powerful people meet in the same room, new ideas do come by, not such a good news to us developers who have scratched their brains and pulled up hours to wrap up the initial implementation.  Although, I believe it is a good venue when time is on your side to learn something new. 🙂

This is exactly what happened to us, the requirement sounds pretty simple, but took me few hours to find an optimum solution which solves the problem, but, also would not involve too many changes to existing logic in play.
Goal –   Get all the results that match the filters(facets) selected by end user with out the default pagination applied (Coveo has default pagination and only pulls the values entered in Number of results value given on the rendering properties).   After few hours of going over Coveo documentation, I found something though completely not the same as what I was looking for, it kind of sparked the similar wave of implementation.

I almost always start a Q&A either to confirm my thoughts or to see if there are any other ways to accomplish the same.   In this case, what i was going for just felt right and Coveo team member confirmed the same.  You can follow the trail here.

https://answers.coveo.com/questions/10368/do-we-have-allnot-limited-to-resultsperpage-result.html

So, basically to achieve what I was looking for, you need to fire a parallel query with exact same filters based on user interaction and simply change the results to an upper bound.  It would have been nice to actually set it to Totalresults, I have not tried that, but, could work when you get the value from the correct variable.

Here is a snippet –

Coveo.$(‘#<%= Model.Id %>’).on(Coveo.QueryEvents.querySuccess,function(e, args)
{
var query = args.query;
query.numberOfResults = 2;
//Do any other modifications on the query
Coveo.SearchEndpoint.endpoints[“default”].search(query).done(function(data) {
//do any other logic on the data up here
}
});
});

That is it, we have everything we need plus a handler over all results.  I am pretty sure it would come up often hopefully it helps any one else.

Happy problem solving folks. 🙂