1:56 p.m.
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/ee776744760d8115...
(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
11:05 p.m.
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(a)gmail.com> wrote:
2:58 p.m.
Hi Sanne,
Thanks for your feedback. My answers below:
On Thu, May 14, 2015 at 11:05 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Yes, it's not hard at all. I removed the FieldCustomization interface from
PlainTextMatchingContext.
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.
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
3578
days inactive
3580
days old
2 comments
2 participants
participants (2)
-
Guillaume Smet -
Sanne Grinovero