Thanks for your feedback. My answers below:
On Thu, May 14, 2015 at 11:05 PM, Sanne Grinovero <sanne(a)hibernate.org>
- ignoreAnalyzer() I agree with your comment, it doesn't seem to
much sense. But what about not having the method rather than making it
throw an exception?
I'm assuming that should be possible by making some changes in the
interfaces, but I didn't try so I might be missing some complexity.
Yes, it's not hard at all. I removed the FieldCustomization interface from
- ignoreFieldBridge() This one is more controversial. I think
generally we should accept the types in their original form, so for
example accept a parameter which is not a String but a custom user
type, for which a field bridge or some two-way StringBridge could be
registered, and we apply the conversion automatically.
We do this on other APIs and we should be consistent across methods,
although there are some obscure ambiguities with that choice, for
example we do apply the FieldBridge from the field *name* and not from
the runtime type of the parameter, which introduces some complexities
when the query is targeting multiple fields with different indexing
options, especially if the input is expected to be in different types.
Plain text search only supports String search. It tokenizes and parses the
string to build the query term by term (and terms might be operators,
negative queries, fuzzy queries...). You cannot apply a StringBridge to the
whole string and you cannot apply a StringBridge to each term after the
That's why I'm thinking it's a limitation we should accept.
I don't think these implications were too clear when we first
the DSL, so not ruling out a change of direction to be considered for
the next major version; you feedback as power user would be essential.
I still think that it's convenient for example to automatically encode
a Date type, but the type should then be matched differently to each
field.. how could we do that using this Lucene parser?
Well, it's not how this parser works, that's why I called it text search.
I tighten the DSL a bit in a further commit.
As for the current code, I don't really like the .defaultOperatorIsAnd()
method name. Any better ideas?
Another pain point which your tests are highlighting, is the lack of
an easy to use, short hand for the sorting API. Created HSEARCH-1872
as a discussion point.
If we're talking about the limitations of the DSL, let's tackle this
Here are the main reasons why we are forced to not use the DSL (or at least
add a layer on top of it):
- ability to search on multiple fields with an AND operator: we used the
Lucene MultiFieldsQueryParser, we now have switched to the
SimpleQueryParser (what I propose here would solve this issue)
- ability to ignore a condition if the term (term in a general way) is
null: most of the time, users only define 1 or 2 fields of the search
engine and we want to ignore this part of the query if the term is null.
Currently, we end up with a lot of boilerplate code.
- ability to ignore a query if the query is null (typically a boolean
junction and a for loop with no items)