Paul Elschot wrote:
Paul, I think the surround syntax is very logical, and looks quite
powerful. From my perspective, it is the right fit syntax for the job.
My main issue was probably lack of understanding. I decided to stick
with the tool I've gained a little understanding over now.
The goal(s) I am trying to accomplish is rather specific I think,
so I imagine the use of my is rather limited (i.e. just to
Are you using QueryParser? If so, you'll also want to account for
At the moment my code:
* parses the search text (i.e. user entered query)
The surround parser can create both boolean queries and span queries.
Sean, as you seem to prefer not to use the surround syntax, do you think
this syntax could be improved somehow? I recall trying to make it simpler,
but when I made it I was not able to do so.
When I looked at using surround queries, I believe I got stuck finding
access to the spans information. I was pressed for time, and only looked
it over for a couple of hours. A good portion of that was setup time. I
probably missed some of the more obvious points, so I will go back and
look over the surround code to see how unencumbered by the thought
process I was when I decided to reinvent my wheel.
This intrigues me. I know I don't understand Lucene past the basics, so
I'm a little lost on the implications of your suggestion.
My impression was (and still is) that PhraseQuery is a significantly
different implementation from the SpanQuery family. Is it rather
straightforward to implement getSpans() for a PhraseQuery? Granted, I
seem to have missed that Surround is based on SpanQueries, so it looks
like I need to spend some more time getting my head straight on these
Also, PhraseQuery is more efficient than a combination of SpanTermQuery,
SpanOrQuery and SpanNearQuery, so perhaps PhraseQuery should have
a getSpans() method so it could be used as a SpanQuery, too.
Thanks for your comments,
To unsubscribe, e-mail: java-user-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: java-user-help@xxxxxxxxxxxxxxxxx