Feature request: Ability to save partial queries to abstract search details

Elastic Stack Elasticsearch
1

Hey!
Wanted to throw this idea out there to see if it would be useful to
others. I think it'd be very nice to be able to save query/partial queries
that that can then be re-used. This would allow inputs in web
code/application to be abstracted away from some of the nitty gritty
implementation details and provide a cleaner overall interface.
Furthermore, the search behavior could be tweaked via updating the
configuration instead of changing code.

The way to do it is to have pseudo fields (defined in the mapping) and
saved named queries (that reference the psuedo field they belong to) that
can be passed in as inputs for that psuedo field, eg:
FieldName: NewsType

FieldValues:
Announcements = feedid:(1323 OR 1330) AND NOT headline:"test message"
News = feedid:600 AND providercode:"6003"
BreakingNews = feedid:600 AND providercode:"6003" AND hotnews:1

So, an example query would simply be:
NewsType:BreakingNews

It seems similar is already done to some extent with percolation and that
same pattern could likely be used.

Thanks!
Paul

--

2

Seems useful to me... though I wonder if this really needs to live in ES,
or whether it should just be built on top of it.

Otis

ELASTICSEARCH Performance Monitoring - Sematext Monitoring | Infrastructure Monitoring Service
Search Analytics - Cloud Monitoring Tools & Services | Sematext

On Wednesday, November 21, 2012 5:06:52 PM UTC-5, ppearcy wrote:

Hey!
Wanted to throw this idea out there to see if it would be useful to
others. I think it'd be very nice to be able to save query/partial queries
that that can then be re-used. This would allow inputs in web
code/application to be abstracted away from some of the nitty gritty
implementation details and provide a cleaner overall interface.
Furthermore, the search behavior could be tweaked via updating the
configuration instead of changing code.

The way to do it is to have pseudo fields (defined in the mapping) and
saved named queries (that reference the psuedo field they belong to) that
can be passed in as inputs for that psuedo field, eg:
FieldName: NewsType

FieldValues:
Announcements = feedid:(1323 OR 1330) AND NOT headline:"test message"
News = feedid:600 AND providercode:"6003"
BreakingNews = feedid:600 AND providercode:"6003" AND hotnews:1

So, an example query would simply be:
NewsType:BreakingNews

It seems similar is already done to some extent with percolation and that
same pattern could likely be used.

Thanks!
Paul

--

3

Hi Paul,

I would suggest a query language as a front-end. For example, I have
implemented an SRU/CQL parser

http://www.loc.gov/standards/sru/

that translates bibliographic queries to Elasticsearch DSL. CQL is very
simple compared to ES DSL. Although the translator is using an LALR parser,
there is somewhat a similarity to your suggestion of building a "macro
list" of query phrases, but LALR parsers are more powerful.

The advantage of the separation of a front-end query language from the ES
back-end query language is that you can add or replace the back-end with
other systems by adapting the translator, so from a front-end view you can
even do federated search, if the response output formats can be
consolidated.

Cheers,

Jörg

--

4

Thanks for the feedback. For most cases, I agree doing this front end makes
more sense. However, when you start saving queries for percolation things
get more complicated, since you then need to keep the saved sub-queries in
sync with what is saved down in elasticsearch.

On Monday, November 26, 2012 2:17:13 AM UTC-7, Jörg Prante wrote:

Hi Paul,

I would suggest a query language as a front-end. For example, I have
implemented an SRU/CQL parser

SRU: Search/Retrieval via URL -- SRU, CQL and ZeeRex (Standards, Library of Congress)

that translates bibliographic queries to Elasticsearch DSL. CQL is very
simple compared to ES DSL. Although the translator is using an LALR parser,
there is somewhat a similarity to your suggestion of building a "macro
list" of query phrases, but LALR parsers are more powerful.

The advantage of the separation of a front-end query language from the ES
back-end query language is that you can add or replace the back-end with
other systems by adapting the translator, so from a front-end view you can
even do federated search, if the response output formats can be
consolidated.

Cheers,

Jörg

--

5

Do you miss an API for listing the queries in the percolator?

Jörg

--