Blog
Scoping Queries in the Optic API
- 28 July, 2022
- By Dave Cassel
Every now and then I write an Optic query that has parts that look redundant. In the example below, assume the 4V.Sample view has a “keyCode” field and that the JSON docs the view is built from have a “keyProp” property. My goal is to gather some information from a view for a specific set of values. The set of values is itself the result of a calculation.
// Get an array of objects that include a "code" property.
// These are the interesting ones to use in our query.
const myKeys = buildKeys();
// Make an array of just the code values
let myKeyCodes = myKeys.map(item => item.code);
let result = op
.fromLiterals(myKeys)
.joinLeftOuter(
op
.fromView("4V", "Sample")
.where(cts.jsonPropertyValueQuery("keyProp", myKeys)),
op.on(op.col("code"), op.col("keyCode"))
)
.limit(100)
.result()
.toArray();
let response = {
time: xdmp.elapsedTime(),
result
};
response
Notice the .where clause. This is a scoping query that narrows down the possibilities to consider in the rest of the query. Of course, with the joinLeftOuter, it’s redundant — we’ll get the same results with or without that .where, because we’re only going to produce one row for each row on the left (the literals).
So why bother? Performance.
I ran this query multiple times with and without the .where clause on a data set with about 750,000 rows in the 4V.Sample view. Without the clause, it took just short of 3 seconds to run. With the clause, it was about 0.1 seconds. Big difference!
Share this post:
4V Services works with development teams to boost their knowledge and capabilities. Contact us today to talk about how we can help you succeed!
Every now and then I write an Optic query that has parts that look redundant. In the example below, assume...