[hibernate-dev] Search - Plain text and SimpleQueryParser

[Sanne Grinovero]

Hi Guillaume, welcome back!

I love the usability of this, I agree we should expose this
functionality. The "text()" method seems a good choice too.

On some other details:

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

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

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?

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.

Thanks,
Sanne



On 13 May 2015 at 12:56, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> Having some spare time, I revisited my patch that used the Lucene
> SimpleQueryParser to provide more advanced search features to the end user.
>
> At my company, our search requirements are usually the following:
> - a full text search on the name and description;
> - a set of dropdown choices.
>
> Our full text search uses the AND operator as our customers usually
> requires this. It's not something we can do with the current keyword()
> search (I described the issue at length in
> https://hibernate.atlassian.net/browse/HSEARCH-917).
>
> We often give the ability to use boolean operators and phrase queries to
> the end user.
>
> How did we expose this feature? We build a Lucene query using the
> MultiFieldsQueryParser and we set the default operator to AND. We can't use
> the DSL.
>
> Starting with Lucene 4, we have a nice parser which is called
> SimpleQueryParser and which is... simple and resilient. And I think it
> would be a good idea to expose it via the DSL.
>
> It currently looks like this:
> https://github.com/openwide-java/hibernate-search/commit/ee776744760d8115965a05c939227d24133b58ec
> (there's not much code, Lucene is doing the magic).
>
> There are a couple of XXX I would like to discuss and I'm not that thrilled
> with the names I gave to the options.
>
> I have some spare time this week and next week so I'll be able to polish
> the patch based on your feedback!
>
> Have a nice day.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev