2:21 p.m.
As reported on SO [1], it's not a straight forward migration for those
who embraced the convenience of using a MultiFieldQueryParser, or one
of the other Lucene provided parsers.
In the specific example, I think the right answer would be to use the
programmatic API or our DSL.. but let's consider the use case in which
you want to parse user input, from a text input in your application?
Using the parser is quite convenient in such a case, as people can
express boolean operators and field names, while keeping the UI very
simple.
Wouldn't it be nice to have a custom "parser" in our DSL, which
essentially mimicks the functionality of the MultiFieldQueryParser but
takes advantage of our indexing metadata - like we do for the HQL
Parser?
Sanne
1 -
http://stackoverflow.com/questions/28138308/hibernate-search-5-0-numeric-...
2:39 p.m.
Hi,
On Mon, Jan 26, 2015 at 01:21:20PM +0000, Sanne Grinovero wrote:
As reported on SO [1], it's not a straight forward migration for
those
who embraced the convenience of using a MultiFieldQueryParser, or one
of the other Lucene provided parsers.
That is correct, but we knew that right? The docs explain the situation and
we need to make sure that we answer these type of questions.
In the specific example, I think the right answer would be to use
the
programmatic API or our DSL..
It depends. If the user wants to keep the old behaviour and is happy with
it, he can just make sure that the numeric values as indexed as strings.
Personally, I am not going to recommend to switch to the DSL.
Wouldn't it be nice to have a custom "parser" in our
DSL, which
essentially mimicks the functionality of the MultiFieldQueryParser but
takes advantage of our indexing metadata - like we do for the HQL
Parser?
We could in fact do that. I thought there was even an issue for that.
If not I at least wanted to create one ;-) As you are saying, we have the
required information (whether a field is numeric or not) available. So we could
write a custom QueryParser which takes this into account. We might even not
only use it in the DSL, but also make it available standalone
--Hardy.
3:01 p.m.
Yes but let’s put it in perspective to all the goals we have :)
On 26 Jan 2015, at 14:21, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
As reported on SO [1], it's not a straight forward migration for those
who embraced the convenience of using a MultiFieldQueryParser, or one
of the other Lucene provided parsers.
In the specific example, I think the right answer would be to use the
programmatic API or our DSL.. but let's consider the use case in which
you want to parse user input, from a text input in your application?
Using the parser is quite convenient in such a case, as people can
express boolean operators and field names, while keeping the UI very
simple.
Wouldn't it be nice to have a custom "parser" in our DSL, which
essentially mimicks the functionality of the MultiFieldQueryParser but
takes advantage of our indexing metadata - like we do for the HQL
Parser?
Sanne
1 -
http://stackoverflow.com/questions/28138308/hibernate-search-5-0-numeric-...
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:13 p.m.
On Mon, Jan 26, 2015 at 03:01:17PM +0100, Emmanuel Bernard wrote:
Yes but let’s put it in perspective to all the goals we have :)
Right, same with the potential Search 5 upgrade (I also think we should
do it asap). It is all a question of priority and the time we have to work
on this.
--Hardy
4:49 p.m.
On Mon, Jan 26, 2015 at 03:39:14PM +0100, Emmanuel Bernard wrote:
> Right, same with the potential Search 5 upgrade (I also think we
should
> do it asap).
I am not following you on that? We are at Hibernate Search 5 already.
Sorry, meant to write Lucene 5, referring to Sanne's email from earlier.
--Hardy
3644
days inactive
3644
days old
5 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero