On Thu, Oct 11, 2012 at 8:08 AM, Shay Banon email@example.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
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 firstname.lastname@example.org 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
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!