Develop CtsQueryBuilder

[sammefford]

Functionality should mirror StructuredQueryBuilder, but the output should be a serialized cts query rather than a structured query. This is needed for integration with mlcp since it can only accept cts queries.

[sammefford]

The priority on this is much lower now since data-movement sdk will not build on top of mlcp, so it will have available all queries supported by the java-client API.

[sammefford]

Assigning this to you Erik, since you said you were code generating it

[ehennum]

Optic payload is in EA3. The cts.query JSON serialization is a goal for EA4.

[grechaw]

Should this issue be moved to a later milestone?

[sammefford]

In a conversation with Erik just now he clarified the intended implementation of the JSON or XML serialization. His intention is to provide a wrapper class that implements QueryDefinition and thus provides setCollections and setDirectory. (Aside: That would also expose setOptionsName, but I don't expect clients to use that here as it wouldn't help a cts query. Maybe the REST endpoint could even throw an error when an options name is provided together with a cts query.) The wrapper class would call a method on the cts query object to serialize to JSON or XML.

In any case, the current cts query builder will work great for those using the Optic API. But for those that want to send a cts query to filter a search request or other places that accept a QueryDefinition, they'll have to wait until this wrapper class is implemented. Until then it shouldn't be confusing for end-users because it will be clear for them how to use a cts query with optic API but not with methods requiring a QueryDefinition.

[ehennum]

Setting to 9.0-1 because that's the milestone available but really this work will need to wait until after 9.0-1

[ehennum]

Moving out of 9.0-1 now that a later milestone is available.

[jmakeig]

Once this is available—which I’d like to prioritize—is there any reason to not deprecate StructuredQueryBuilder? SQB lives in the uncanny valley.

[ehennum]

I believe that StructuredQueryBuilder provides an interface only for the query definition, which by definition means that it can't support anything that a CtsQueryBuilder wouldn't support.

Note that an interface for defining bindings for cts:parse() is still a desiderata -- but then, so is support for cts:parse() in the REST API.

[ehennum]

Question: instead of changing the client CtsQuery builder to emit two serializations, should the /v1/search REST API endpoint just process the AST representation of a cts:query()?

[sammefford]

That seems to me to meet the highest priority need. It would, of course, need to accept the AST representation in a combined query also since that's required to specify facets, values, tuples, etc. The main limitation I can see is it would probably output only XML which would prevent customers from specifying the rest of their combined query in JSON when combining with this. But we already have that limitation with StructuredQueryBuilder and would probably have had the same limitation with a new CtsQueryBuilder.

[ehennum]

For consideration, balancing other objectives.