[hibernate-dev] [AND] Search: changing the way we search

[Guillaume Smet]

On Thu, Mar 20, 2014 at 3:08 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> I tend to disagree with you. The SimpleQueryBuilder seems to disagree
> with you too as SHOULD is the default. Care to give your arguments in
> favor of a different value for the default?

Well, IMHO, this feature is designed for a specific purpose and is not
a general implementation. That's why I'm not considering me tied up by
choices of general implementations.

I think when a user is looking for "something precise", he wants
results which satisfies his queries.

That said I'm open to keep it the other way. It's just that I really
prefer an AND default from a user point of view. FWIW every time we
forgot to change the operator, we have a ticket open by our customers
as soon as they search something.

I was thinking about renaming the option:
use(And|Or)AsDefaultOperator(). Not exactly elegant but it's what it
really does.

>> Where I would like advice/opinion:
>> - does it look like a good idea or something horrible?
>
> Yes that looks interesting to me. This machine is hard to describe to a
> human though except with "it does the right thing... most of the time" :)

Yes, that's the purpose of this feature. From my point of view, if we
consider one day that a eDismax parser is more suitable for it, we
might move to this new parser.

>> - I'm still hesitant about what to do with field bridges: atm, I don't
>> take them into account at all
>
> The way I look at it, you won't likely be able to support fields that
> are not texts in the first place.
> So you could raise some exception if a selected field is not a
> String field bridge. And we can expand from there.

Will do.

>> - I think having a DSL branch for text search is necessary even if it
>> might seem very similar to term search
>
> I feel that you are right on that one but can you try and write down
> your arguments?

Well, there are a couple of good reasons AFAICS:
- text() implementation is limited (see the FieldBridge limitation
above) and totally different from the term() one. I really don't like
the idea to expose it to the user as an option to the term() search.
It's definitely a totally different thing and it's important to show
it;
- in the long term, I'm not sure the choices made for text() and
term() will be the same. We might want to add option to one or another
and not both. This second reason is kinda related to the first one.
Typically, I would like to add a minimum should match option one day.

> Note that the QueryBuilder.createFieldQuery seems to do the right thing
> when it comes to applying SHOULD between overlapping tokens and the
> selected operator between "words" but I did not dive too much into the
> logic.

Yep. That's one of the reasons why I want to use the Lucene machinery.
I'm not sure QueryBuilder.createFieldQuery *always* does the right
thing but it's certainly far better than the naive approach.

-- 
Guillaume