are now legal ... the querysyntax docs should be modified to mention this in the patch as well.

one hitch: this seems to break backwards compatibility for anyone who has previously subclassed QueryParser and overridden the getRangeQuery(String, String, String, boolean) method ... if someone defines that method in their query parser, it will now never be called – even if they don't take advantage of the new syntax.

off the top of my head, one way to remain backwards compatible is to have a deprecated getRangeQuery(String, String, String, boolean) method which does the same thing it currently does, and have the new getRangeQuery(String, String, String, boolean, boolean) method call it if the booleans have the same value ... if they don't have the same value then do the new stuff. document that people subclassing QueryParser that want to override RangeQueries only need to override the double boolean method.

Hoss Man
added a comment - 13/Sep/07 19:01
so this changes the query syntax such that foo:
{a TO z] and foo:[a TO z}
are now legal ... the querysyntax docs should be modified to mention this in the patch as well.
one hitch: this seems to break backwards compatibility for anyone who has previously subclassed QueryParser and overridden the getRangeQuery(String, String, String, boolean) method ... if someone defines that method in their query parser, it will now never be called – even if they don't take advantage of the new syntax.
off the top of my head, one way to remain backwards compatible is to have a deprecated getRangeQuery(String, String, String, boolean) method which does the same thing it currently does, and have the new getRangeQuery(String, String, String, boolean, boolean) method call it if the booleans have the same value ... if they don't have the same value then do the new stuff. document that people subclassing QueryParser that want to override RangeQueries only need to override the double boolean method.

Andrew Schurman
added a comment - 14/Sep/07 20:49 Your absolutely right, I had a problem with the Solr src extending this method. I don't think there is a nice way to cover all the bases here, but I've updated the code help alleviate the problem.
I believe the only thing that isn't covered is parsing foo:{a TO bat] with useOldRangeQueries=false. Classes that extend will still get a query back, but it might not be what they expect.

Mark Miller
added a comment - 13/Nov/08 02:22 Bit of a pain catching everything that was slightly off, but I think we want this, especially since RangeQuery accepts separate start/end point inclusive/exclusive now.
Patch brings everything up to trunk, but definitely still needs a strong look over. I'll come back to it in a few days.

Missed that the new tests didn't patch, so I've merged and fixed them. Looks pretty good now except that a contrib test fails - those that overrode the deprecated protected Query getRangeQuery(String field, String part1, String part2, boolean inclusive) are being left out in the cold.

Mark Miller
added a comment - 16/Nov/08 16:42 Missed that the new tests didn't patch, so I've merged and fixed them. Looks pretty good now except that a contrib test fails - those that overrode the deprecated protected Query getRangeQuery(String field, String part1, String part2, boolean inclusive) are being left out in the cold.
Once that is addressed, I think this patch looks pretty good.

Luis Alves
added a comment - 25/Aug/09 09:06 Issue LUCENE-1823 includes syntax for >=, <=, = :
Instead of "foo:[a TO z}" the query would be "foo >a AND foo <=z"
instead of "foo:{a TO z]" the query would be "foo >= a AND foo <z"
Is that good enough?

OK, here's the full patch.
Rather than try to maintain back compat for overriders that only works half of the time and silently fails the other half, I took a different approach that will make their compile fail (since lucene4 isn't a drop in replacement for any previous impl).

Yonik Seeley
added a comment - 22/Oct/10 21:01 OK, here's the full patch.
Rather than try to maintain back compat for overriders that only works half of the time and silently fails the other half, I took a different approach that will make their compile fail (since lucene4 isn't a drop in replacement for any previous impl).