Hello,
I like the idea of a parser using the Google syntax (you don't have
to disable explicit fields BTW - recognzing a term:term syntax
should be doable). The hard problem to crack is what's behind. I
explain that in Hibernate Search in Action, a lot of good search
engine do searches in
Hello,
Writing such a queryparser is really easy if you consider acceptable
to catch "QueryParseException"s
what I usually do in case of such an exception is report a JSF
validation error with some instructions about
query syntax.
Well, Google doesn't show validation exceptions if you mistype th
I like the idea of a parser using the Google syntax (you don't have to
disable explicit fields BTW - recognzing a term:term syntax should be
doable). The hard problem to crack is what's behind. I explain that in
Hibernate Search in Action, a lot of good search engine do searches in
tiers:
Hello Adam,
I agree with you that the Seam example could include a better parser,
but that's just an example
and maybe they just wanted to keep it simple. As you say, there could
be a parser provided
with HSearch to keep the example code simple but what is missing in
your opinion?
Writing such a qu
Hello,
in fact I was facing similar problems before, however the problem is
more of a Lucene problem than a Hibernate Search one.
Sure, but it doesn't mean HS can't solve it :)
There are some threads regarding "error tolerant" query parsers on
the Lucene mailing list. There are several appr
Hi Adam,
in fact I was facing similar problems before, however the problem is more
of a Lucene problem than a Hibernate Search one.
There are some threads regarding "error tolerant" query parsers on the
Lucene mailing list. There are several approaches to the problem.
You could catch the Pars
