Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
6 of 6

Use a generic representation of queries in the DSL

Fixed

Description

Currently, queries are internally (and externally, in fact) represented as Lucene Queries, even when querying Elasticsearch. The Query DSL returns Lucene Queries, for instance.

We should have a representation of queries that abstracts itself from actual indexing services, so as to eventually be able to model queries that do more than what Lucene does. For instance, "exists" queries for Elasticsearch, or boolean term queries.

is followed up by

relates to

required for

Details

Assignee

Reporter

Components

Fix versions

Priority

Created December 2, 2016 at 9:24 AM
Updated November 28, 2018 at 3:43 PM
Resolved April 25, 2018 at 9:28 AM

Activity

Show:

Yoann RodièreApril 25, 2018 at 9:28 AM

Resolved as part of the Search 6 proof of concept groundwork.

We introduced the concept of "predicates" to build what was previously called queries, and the interface SearchPredicate to allow to manipulate a built predicate in a generic way.

Followed up by

Yoann RodièreJanuary 27, 2017 at 3:28 PM

Some examples of what user code could be, discussed during the F2F meeting.
Note that must() could either return a "must context" or accept a lambda as a parameter, or we could have two version of the method. We couldn't agree on that yet, we should discuss it further.

Sanne GrinoveroDecember 2, 2016 at 12:20 PM

We also need to keep in mind that the translation of an "internal representation" of a Query into a native query will not depend only on the target technology (Elasticsearch,Lucene,others?) but also on the metadata we have about the specific properties/fields.

An excellent example is the "exists" query; with Lucene it might commonly be a TermQuery but it could also be looking into the bitsets of a docvalues set, if there is one.

Flag notifications