# Leveraging the query parser **URL:** \ **Category:** Elasticsearch\ **Created:** [October 8, 2012, 6:29pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277 "2012-10-08T18:29:50Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [October 8, 2012, 6:29pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/1 "2012-10-08T18:29:50Z")
Part of my system accepts strings in the Lucene syntax, which are either single terms "123" or groups "(123 4 3412)". With Lucene, I can use a QueryParser to parse a query string and it would return either a TermQuery or a BooleanQuery. In ElasticSearch, the QueryParser requires a QueryParseContext, which means it probably cannot be used outside the context of ElasticSearch. Parsing on the client side also allows me to check for potential errors in the string. My current solution is to use Lucene's QueryParser and convert Lucene Querys into their ElasticSearch equivalent. Does a better way exist using straight ElasticSearch? Either a way to create a simple QueryParseContext or a QueryBuilder that accepts a Lucene Query. Cheers, Ivan -- ---
**Author:** ![Mark\_Waddle](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_waddle/32/2608_2.png) [@Mark\_Waddle](https://discuss.elastic.co/u/Mark_Waddle)\ **Post date:** [October 8, 2012, 9:53pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/2 "2012-10-08T21:53:29Z")
The Query DSL supports Lucene queries via the "query\_string" query. See > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. . To validate your queries I recommend using the Validate API, as documented at [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/validate.html). On Monday, October 8, 2012 11:30:00 AM UTC-7, Ivan Brusic wrote: > Part of my system accepts strings in the Lucene syntax, which are either > single terms "123" or groups "(123 4 3412)". > > With Lucene, I can use a QueryParser to parse a query string and it would > return either a TermQuery or a BooleanQuery. In Elasticsearch, the > QueryParser requires a QueryParseContext, which means it probably cannot be > used outside the context of Elasticsearch. Parsing on the client side also > allows me to check for potential errors in the string. > > My current solution is to use Lucene's QueryParser and convert Lucene > Querys into their Elasticsearch equivalent. Does a better way exist using > straight Elasticsearch? Either a way to create a simple QueryParseContext > or a QueryBuilder that accepts a Lucene Query. > > Cheers, > > Ivan -- ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [October 8, 2012, 10:56pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/3 "2012-10-08T22:56:45Z")
I am very aware of the query\_string query. I am looking for behavior analogous to Lucene's QueryParser. My workflow is not suited for the Validate API. Only a portion of the query (actually, the filter) is derived from string in question. If the string is invalid, it is dropped from the query. The Validate API is all-or-nothing, it does not easily identify the offending subclause. Besides, it requires a network hop. Cheers, Ivan On Mon, Oct 8, 2012 at 2:53 PM, Mark Waddle [mark@markwaddle.com](mailto:mark@markwaddle.com) wrote: > The Query DSL supports Lucene queries via the "query\_string" query. See > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/query-dsl/query-string-query.html) > . > > To validate your queries I recommend using the Validate API, as documented > at [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/validate.html). > > On Monday, October 8, 2012 11:30:00 AM UTC-7, Ivan Brusic wrote: > > > Part of my system accepts strings in the Lucene syntax, which are either > > single terms "123" or groups "(123 4 3412)". > > > > With Lucene, I can use a QueryParser to parse a query string and it would > > return either a TermQuery or a BooleanQuery. In Elasticsearch, the > > QueryParser requires a QueryParseContext, which means it probably cannot be > > used outside the context of Elasticsearch. Parsing on the client side also > > allows me to check for potential errors in the string. > > > > My current solution is to use Lucene's QueryParser and convert Lucene > > Querys into their Elasticsearch equivalent. Does a better way exist using > > straight Elasticsearch? Either a way to create a simple QueryParseContext > > or a QueryBuilder that accepts a Lucene Query. > > > > Cheers, > > > > Ivan > > -- -- ---
**Author:** ![Chris\_Male](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chris_male/32/2607_2.png) [@Chris\_Male](https://discuss.elastic.co/u/Chris_Male)\ **Post date:** [October 9, 2012, 3:03am UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/4 "2012-10-09T03:03:30Z")
Hi, I'm a little lost as to what you're trying to do. Are you wanting to parse your query on the client side for validation and then send it to ES to execute? On Tuesday, October 9, 2012 11:56:50 AM UTC+13, Ivan Brusic wrote: > I am very aware of the query\_string query. I am looking for behavior > analogous to Lucene's QueryParser. > > My workflow is not suited for the Validate API. Only a portion of the > query (actually, the filter) is derived from string in question. If the > string is invalid, it is dropped from the query. The Validate API is > all-or-nothing, it does not easily identify the offending subclause. > Besides, it requires a network hop. > > Cheers, > > Ivan > > On Mon, Oct 8, 2012 at 2:53 PM, Mark Waddle \<[ma...@markwaddle.com](mailto:ma...@markwaddle.com)\ > > > wrote: > > > The Query DSL supports Lucene queries via the "query\_string" query. See > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/query-dsl/query-string-query.html) > > . > > > > To validate your queries I recommend using the Validate API, as > > documented at > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/validate.html). > > > > On Monday, October 8, 2012 11:30:00 AM UTC-7, Ivan Brusic wrote: > > > > > Part of my system accepts strings in the Lucene syntax, which are either > > > single terms "123" or groups "(123 4 3412)". > > > > > > With Lucene, I can use a QueryParser to parse a query string and it > > > would return either a TermQuery or a BooleanQuery. In Elasticsearch, the > > > QueryParser requires a QueryParseContext, which means it probably cannot be > > > used outside the context of Elasticsearch. Parsing on the client side also > > > allows me to check for potential errors in the string. > > > > > > My current solution is to use Lucene's QueryParser and convert Lucene > > > Querys into their Elasticsearch equivalent. Does a better way exist using > > > straight Elasticsearch? Either a way to create a simple QueryParseContext > > > or a QueryBuilder that accepts a Lucene Query. > > > > > > Cheers, > > > > > > Ivan > > > > -- -- ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [October 9, 2012, 6:41pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/5 "2012-10-09T18:41:03Z")
Looking to create queries from a string. These queries are only part of the overall query. The standard approach in Lucene using a QueryParser does not work in Elasticsearch since the API requires a QueryParseContext. Looking to create term queries or boolean queries with term queries, not query string queries (exactly as in Lucene). On Mon, Oct 8, 2012 at 8:03 PM, Chris Male [gento0nz@gmail.com](mailto:gento0nz@gmail.com) wrote: > Hi, > > I'm a little lost as to what you're trying to do. Are you wanting to > parse your query on the client side for validation and then send it to ES > to execute? > > On Tuesday, October 9, 2012 11:56:50 AM UTC+13, Ivan Brusic wrote: > > > I am very aware of the query\_string query. I am looking for behavior > > analogous to Lucene's QueryParser. > > > > My workflow is not suited for the Validate API. Only a portion of the > > query (actually, the filter) is derived from string in question. If the > > string is invalid, it is dropped from the query. The Validate API is > > all-or-nothing, it does not easily identify the offending subclause. > > Besides, it requires a network hop. > > > > Cheers, > > > > Ivan > > > > On Mon, Oct 8, 2012 at 2:53 PM, Mark Waddle [ma...@markwaddle.com](mailto:ma...@markwaddle.com) wrote: > > > > > The Query DSL supports Lucene queries via the "query\_string" query. See > > > [http://www.elasticsearch](http://www.elasticsearch). **org/guide/reference/query-dsl/** > > > query-string-query.html[http://www.elasticsearch.org/guide/reference/query-dsl/query-string-query.html](http://www.elasticsearch.org/guide/reference/query-dsl/query-string-query.html) > > > . > > > > > > To validate your queries I recommend using the Validate API, as > > > documented at [http://www.elasticsearch](http://www.elasticsearch). **org/guide/reference/api/** > > > validate.html[http://www.elasticsearch.org/guide/reference/api/validate.html](http://www.elasticsearch.org/guide/reference/api/validate.html) > > > . > > > > > > On Monday, October 8, 2012 11:30:00 AM UTC-7, Ivan Brusic wrote: > > > > > > > Part of my system accepts strings in the Lucene syntax, which are > > > > either single terms "123" or groups "(123 4 3412)". > > > > > > > > With Lucene, I can use a QueryParser to parse a query string and it > > > > would return either a TermQuery or a BooleanQuery. In Elasticsearch, the > > > > QueryParser requires a QueryParseContext, which means it probably cannot be > > > > used outside the context of Elasticsearch. Parsing on the client side also > > > > allows me to check for potential errors in the string. > > > > > > > > My current solution is to use Lucene's QueryParser and convert Lucene > > > > Querys into their Elasticsearch equivalent. Does a better way exist using > > > > straight Elasticsearch? Either a way to create a simple QueryParseContext > > > > or a QueryBuilder that accepts a Lucene Query. > > > > > > > > Cheers, > > > > > > > > Ivan > > > > > > -- > > > > -- -- ---
**Author:** ![Chris\_Male](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chris_male/32/2607_2.png) [@Chris\_Male](https://discuss.elastic.co/u/Chris_Male)\ **Post date:** [October 10, 2012, 4:18am UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/6 "2012-10-10T04:18:52Z")
So you're doing this on the client side? I think I understand the problem. Some parts your queries need a QueryParser and some don't, right? So you want to parse the some parts of your queries client side and then send the whole overall query to ES. Am I along the right lines now? On Wednesday, October 10, 2012 7:41:14 AM UTC+13, Ivan Brusic wrote: > Looking to create queries from a string. These queries are only part of > the overall query. The standard approach in Lucene using a QueryParser does > not work in Elasticsearch since the API requires > a QueryParseContext. Looking to create term queries or boolean queries with > term queries, not query string queries (exactly as in Lucene). > > On Mon, Oct 8, 2012 at 8:03 PM, Chris Male \<[gent...@gmail.com](mailto:gent...@gmail.com)\ > > > wrote: > > > Hi, > > > > I'm a little lost as to what you're trying to do. Are you wanting to > > parse your query on the client side for validation and then send it to ES > > to execute? > > > > On Tuesday, October 9, 2012 11:56:50 AM UTC+13, Ivan Brusic wrote: > > > > > I am very aware of the query\_string query. I am looking for behavior > > > analogous to Lucene's QueryParser. > > > > > > My workflow is not suited for the Validate API. Only a portion of the > > > query (actually, the filter) is derived from string in question. If the > > > string is invalid, it is dropped from the query. The Validate API is > > > all-or-nothing, it does not easily identify the offending subclause. > > > Besides, it requires a network hop. > > > > > > Cheers, > > > > > > Ivan > > > > > > On Mon, Oct 8, 2012 at 2:53 PM, Mark Waddle [ma...@markwaddle.com](mailto:ma...@markwaddle.com)wrote: > > > > > > > The Query DSL supports Lucene queries via the "query\_string" query. See > > > > [http://www.elasticsearch](http://www.elasticsearch). **org/guide/reference/query-dsl/** > > > > query-string-query.html[http://www.elasticsearch.org/guide/reference/query-dsl/query-string-query.html](http://www.elasticsearch.org/guide/reference/query-dsl/query-string-query.html) > > > > . > > > > > > > > To validate your queries I recommend using the Validate API, as > > > > documented at [http://www.elasticsearch](http://www.elasticsearch). **org/guide/reference/api/** > > > > validate.html[http://www.elasticsearch.org/guide/reference/api/validate.html](http://www.elasticsearch.org/guide/reference/api/validate.html) > > > > . > > > > > > > > On Monday, October 8, 2012 11:30:00 AM UTC-7, Ivan Brusic wrote: > > > > > > > > > Part of my system accepts strings in the Lucene syntax, which are > > > > > either single terms "123" or groups "(123 4 3412)". > > > > > > > > > > With Lucene, I can use a QueryParser to parse a query string and it > > > > > would return either a TermQuery or a BooleanQuery. In Elasticsearch, the > > > > > QueryParser requires a QueryParseContext, which means it probably cannot be > > > > > used outside the context of Elasticsearch. Parsing on the client side also > > > > > allows me to check for potential errors in the string. > > > > > > > > > > My current solution is to use Lucene's QueryParser and convert Lucene > > > > > Querys into their Elasticsearch equivalent. Does a better way exist using > > > > > straight Elasticsearch? Either a way to create a simple QueryParseContext > > > > > or a QueryBuilder that accepts a Lucene Query. > > > > > > > > > > Cheers, > > > > > > > > > > Ivan > > > > > > > > -- > > > > > > -- -- ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [October 10, 2012, 7:21pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/7 "2012-10-10T19:21:11Z")
Correct. The query creation process is actually quite detailed. The QueryParser is used for filters that are "almost" Lucene syntax. Each filter is processed (into Lucene syntax), parsed, reprocessed (adding in things removed in the first step) and added to the overall query. Lucene's QueryParser is a great class. My current solution works, but is a bit kludgy (I hate using instanceof). I have a long history of taking Shay's code and using it in ways that were not meant to be 🙂 [http://forum.compass-project.org/message.jspa?messageID=294616#294616](http://forum.compass-project.org/message.jspa?messageID=294616#294616) Ivan On Tue, Oct 9, 2012 at 9:18 PM, Chris Male [gento0nz@gmail.com](mailto:gento0nz@gmail.com) wrote: > So you're doing this on the client side? I think I understand the problem. > Some parts your queries need a QueryParser and some don't, right? So you > want to parse the some parts of your queries client side and then send the > whole overall query to ES. Am I along the right lines now? -- ---
**Author:** ![Chris\_Male](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chris_male/32/2607_2.png) [@Chris\_Male](https://discuss.elastic.co/u/Chris_Male)\ **Post date:** [October 11, 2012, 2:54am UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/8 "2012-10-11T02:54:06Z")
Hmm... I'm not really sure there is a particularly elegant way of doing this. There has been some development in Lucene ( [[LUCENE-4012] Make all query classes serializable, and provide a query parser to consume them - ASF JIRA](https://issues.apache.org/jira/browse/LUCENE-4012)) to make it easy to convert Queries into JSON. Maybe there is something in that you can pick and misuse 🙂 On Thursday, October 11, 2012 8:21:18 AM UTC+13, Ivan Brusic wrote: > Correct. The query creation process is actually quite detailed. The > QueryParser is used for filters that are "almost" Lucene syntax. Each > filter is processed (into Lucene syntax), parsed, reprocessed (adding in > things removed in the first step) and added to the overall query. Lucene's > QueryParser is a great class. > > My current solution works, but is a bit kludgy (I hate using instanceof). > I have a long history of taking Shay's code and using it in ways that were > not meant to be 🙂 > [http://forum.compass-project.org/message.jspa?messageID=294616#294616](http://forum.compass-project.org/message.jspa?messageID=294616#294616) > > Ivan > > On Tue, Oct 9, 2012 at 9:18 PM, Chris Male \<[gent...@gmail.com](mailto:gent...@gmail.com)\ > > > wrote: > > > So you're doing this on the client side? I think I understand the > > problem. Some parts your queries need a QueryParser and some don't, right? > > So you want to parse the some parts of your queries client side and then > > send the whole overall query to ES. Am I along the right lines now? -- ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [October 11, 2012, 3:08pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/9 "2012-10-11T15:08:29Z")
You current approach is the one that should be used, do you really need to use ES query parser one (because of the mappings support)? On Oct 10, 2012, at 12:21 PM, Ivan Brusic [ivan@brusic.com](mailto:ivan@brusic.com) wrote: > Correct. The query creation process is actually quite detailed. The QueryParser is used for filters that are "almost" Lucene syntax. Each filter is processed (into Lucene syntax), parsed, reprocessed (adding in things removed in the first step) and added to the overall query. Lucene's QueryParser is a great class. > > My current solution works, but is a bit kludgy (I hate using instanceof). I have a long history of taking Shay's code and using it in ways that were not meant to be 🙂 > [http://forum.compass-project.org/message.jspa?messageID=294616#294616](http://forum.compass-project.org/message.jspa?messageID=294616#294616) > > Ivan > > On Tue, Oct 9, 2012 at 9:18 PM, Chris Male [gento0nz@gmail.com](mailto:gento0nz@gmail.com) wrote: > So you're doing this on the client side? I think I understand the problem. Some parts your queries need a QueryParser and some don't, right? So you want to parse the some parts of your queries client side and then send the whole overall query to ES. Am I along the right lines now? > > -- -- ---
**Author:** ![phill](https://avatars.discourse-cdn.com/v4/letter/p/779978/32.png) [@phill](https://discuss.elastic.co/u/phill)\ **Post date:** [October 11, 2012, 4:02pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/10 "2012-10-11T16:02:04Z")
In my case, I'm using the ES query parser, before sending a search off to ES, to get to the parts of what the user has typed and then do some "enhancements". I take the parts from the user query and add 1 or more extra phrases. The extra phrases are made from the 'simple words' in the query (simple = bare terms no explicit boost, field name etc.). Now with ES, I sometimes use the query parts and create queries against both a parent and a child type in the index, but that's all after figuring out the parts provided. Currently, because it was ported from Lucene the class that holds these "simple terms and other phrases" keeps the parts as Lucene BooleanClauses, because (a) the code started in Lucene and that's what the query parser produces and (b) a BooleanClause is sufficient to hold the set of must/should, the field name, the term, the boost. This worked for me because I mostly care about bare 'simple' terms, otherwise clauses can become a query\_string with minimal processing. Ivan mentioned instanceof, the code for the above uses instanceof to recognize TermQuery to find the terms I'll be working with and contains instanceof BooleanQuery, that is all. There is code somewhere that notices if the whole things is a match all query which of course doesn't lead to much need for query 'enhancing'. -Paul On 10/11/2012 8:08 AM, Shay Banon wrote: > You current approach is the one that should be used, do you really > need to use ES query parser one (because of the mappings support)? > > On Oct 10, 2012, at 12:21 PM, Ivan Brusic \<[ivan@brusic.com](mailto:ivan@brusic.com) > [mailto:ivan@brusic.com](mailto:ivan@brusic.com)\> wrote: > > > Correct. The query creation process is actually quite detailed. The > > QueryParser is used for filters that are "almost" Lucene syntax. Each > > filter is processed (into Lucene syntax), parsed, reprocessed (adding > > in things removed in the first step) and added to the overall query. > > Lucene's QueryParser is a great class. > > > > My current solution works, but is a bit kludgy (I hate using > > instanceof). I have a long history of taking Shay's code and using it > > in ways that were not meant to be 🙂 > > [http://forum.compass-project.org/message.jspa?messageID=294616#294616](http://forum.compass-project.org/message.jspa?messageID=294616#294616) > > > > Ivan > > > > On Tue, Oct 9, 2012 at 9:18 PM, Chris Male \<[gento0nz@gmail.com](mailto:gento0nz@gmail.com) > > [mailto:gento0nz@gmail.com](mailto:gento0nz@gmail.com)\> wrote: > > > > ``` > > So you're doing this on the client side? I think I understand the > > problem. Some parts your queries need a QueryParser and some > > don't, right? So you want to parse the some parts of your queries > > client side and then send the whole overall query to ES. Am I > > along the right lines now? > > > > ``` > > > > -- > > -- -- ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [October 11, 2012, 7:28pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/11 "2012-10-11T19:28:24Z")
On Thu, Oct 11, 2012 at 8:08 AM, Shay Banon [kimchy@gmail.com](mailto:kimchy@gmail.com) wrote: > You current approach is the one that should be used, do you really need to > use ES query parser one (because of the mappings support)? Good to know my approach should be correct. What I can't find is how ES uses the Query returned from org.elasticsearch.index.query.QueryParser and transforms it. I don't need mapping support because I already have wonderful workaround for creating ES analyzers on the client-side. On Thu, Oct 11, 2012 at 9:02 AM, P. Hill [parehill1@gmail.com](mailto:parehill1@gmail.com) wrote: > In my case, I'm using the ES query parser, before sending a search off to > ES, to get to the parts of what the user has typed and then do some > "enhancements". > I take the parts from the user query and add 1 or more extra phrases. The > extra phrases are made from the 'simple words' in the query (simple = bare > terms no explicit boost, field name etc.). Now with ES, I sometimes use > the query parts and create queries against both a parent and a child type > in the index, but that's all after figuring out the parts provided. My use case is similar to yours. Constructing a query from many smaller pieces. Like I said, the QueryParser is a great class. > Ivan mentioned instanceof, the code for the above uses instanceof to > recognize TermQuery to find the terms I'll be working with and contains > instanceof BooleanQuery, that is all. There is code somewhere that notices > if the whole things is a match all query which of course doesn't lead to > much need for query 'enhancing'. True, there are only two instanceof checks (TermQuery/BooleanQuery), but if I am using an object-oriented language, I prefer to use OO techniques. Might as well use a dynamic language and duck typing! Cheers, Ivan -- ---
**Author:** ![phill](https://avatars.discourse-cdn.com/v4/letter/p/779978/32.png) [@phill](https://discuss.elastic.co/u/phill)\ **Post date:** [October 11, 2012, 9:12pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/12 "2012-10-11T21:12:05Z")
On 10/11/2012 12:28 PM, Ivan Brusic wrote: > ``` > Ivan mentioned instanceof, the code for the above uses instanceof > to recognize TermQuery to find the terms I'll be working with and > contains instanceof BooleanQuery, that is all. There is code > somewhere that notices if the whole things is a match all query > which of course doesn't lead to much need for query 'enhancing'. > > ``` > > True, there are only two instanceof checks (TermQuery/BooleanQuery), > but if I am using an object-oriented language, I prefer to use OO > techniques. Might as well use a dynamic language and duck typing! I'm at a loss to image walking a tree and finding a node and then not having to ask if the node is a certain type like TermQuery. If you want to call a method on the object to ask if it is a TermQuery you could always use someQuery.getClass().isAssignableFrom(TermQuery.class); 🙂 But that does violates the Law of Demeter, because I formed a small train of method calls, thus creating a potential for a "train wreck". -Paul -- ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [October 15, 2012, 11:16pm UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/13 "2012-10-15T23:16:58Z")
Agreed, QueryParseContext should be an interface, so plugging in mock parsers would be possible. This would be useful for plugins that can perform query rewriting and query transformations, e.g. inserting synonyms, named entities, or spelling corrections with automatic resubmit at server side (and returning the performed query transformations to the client). My rather limited approach now is using the QueryBuilders only, at client side, without Lucene syntax tree, without ES field mapping, for one-phase only query construction. Jörg On Monday, October 8, 2012 8:30:00 PM UTC+2, Ivan Brusic wrote: > Part of my system accepts strings in the Lucene syntax, which are either > single terms "123" or groups "(123 4 3412)". > > With Lucene, I can use a QueryParser to parse a query string and it would > return either a TermQuery or a BooleanQuery. In Elasticsearch, the > QueryParser requires a QueryParseContext, which means it probably cannot be > used outside the context of Elasticsearch. Parsing on the client side also > allows me to check for potential errors in the string. > > My current solution is to use Lucene's QueryParser and convert Lucene > Querys into their Elasticsearch equivalent. Does a better way exist using > straight Elasticsearch? Either a way to create a simple QueryParseContext > or a QueryBuilder that accepts a Lucene Query. > > Cheers, > > Ivan -- ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [October 16, 2012, 7:07am UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/14 "2012-10-16T07:07:07Z")
One more note, org.elasticsearch.test.unit.index.query.SimpleIndexQueryParserTests gives an example how to instantiate an IndexQueryParserService for testing. On Tuesday, October 16, 2012 1:16:58 AM UTC+2, Jörg Prante wrote: > Agreed, QueryParseContext should be an interface, so plugging in mock > parsers would be possible. > > This would be useful for plugins that can perform query rewriting and > query transformations, e.g. inserting synonyms, named entities, or spelling > corrections with automatic resubmit at server side (and returning the > performed query transformations to the client). > > My rather limited approach now is using the QueryBuilders only, at client > side, without Lucene syntax tree, without ES field mapping, for one-phase > only query construction. > > Jörg > > On Monday, October 8, 2012 8:30:00 PM UTC+2, Ivan Brusic wrote: > > > Part of my system accepts strings in the Lucene syntax, which are either > > single terms "123" or groups "(123 4 3412)". > > > > With Lucene, I can use a QueryParser to parse a query string and it would > > return either a TermQuery or a BooleanQuery. In Elasticsearch, the > > QueryParser requires a QueryParseContext, which means it probably cannot be > > used outside the context of Elasticsearch. Parsing on the client side also > > allows me to check for potential errors in the string. > > > > My current solution is to use Lucene's QueryParser and convert Lucene > > Querys into their Elasticsearch equivalent. Does a better way exist using > > straight Elasticsearch? Either a way to create a simple QueryParseContext > > or a QueryBuilder that accepts a Lucene Query. > > > > Cheers, > > > > Ivan -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:08am UTC](https://discuss.elastic.co/t/leveraging-the-query-parser/9277/15 "2017-07-06T03:08:40Z")