[hibernate-dev] Search - Plain text and SimpleQueryParser

[Guillaume Smet]

Hi Sanne,

Thanks for your feedback. My answers below:

On Thu, May 14, 2015 at 11:05 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

>  - ignoreAnalyzer() I agree with your comment, it doesn't seem to make
> 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
PlainTextMatchingContext.


>  - 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
tokenization.

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 created
> 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
subject :).

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)

-- 
Guillaume