: Done. I deprecated DateField and DateFilter, and added the RangeFilter
: class contributed by Chris.
:
: I did a little code cleanup, Chris, renaming some RangeFilter variables
: and correcting typos in the Javadocs. Let me know if everything looks
: ok.
Wow ... that was fast. Things look fine to me (typo's in javadocs are my
specialty) but now I wish I'd included more tests
I still feel a little confused about two things though...
First: Is there any reason Matt Quail's "LongField" class hasn't been
added to CVS (or has it and I'm just not seeing it?)
I haven't tested it extensively, but strikes me as being a crucial utility
for people who want to do any serious sorting or filtering of numeric
values.
Although I would suggest a few minor tweaks:
a) Rename to something like NumberTools (to be consistent with the new
DateTools and because...)
b) Add some one line convinience methods like intToString and
floatToString and doubleToString ala:
return longToString(Double.doubleToLongBits(d));
Second...
: RangeQuery wrapped inside a QueryFilter is more specifically what I
: said. I'm not a fan of DateField and how the built-in date support in
: Lucene works, so this is why I don't like DateFilter personally.
:
: Your RangeFilter, however, is nicely done and well worth deprecating
: DateFilter for.
[...]
: > and RangeQuery. [5] Based on my limited tests, using a Filter to
: > restrict
: > to a Range is a lot faster then using RangeQuery -- independent of
: > caching.
:
: And now with FilteredQuery you can have the best of both worlds :)
See, this is what I'm not getting: what is the advantage of the second
world? :) ... in what situations would using...
s.search(q1, new QueryFilter(new RangeQuery(t1,t2,true));
...be a better choice then...
s.search(q1, new RangeFilter(t1.field(),t1.text(),t2.text(),true,true);
?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
