: Note that I said FilteredQuery, not QueryFilter.
Doh .. right sorry, I confused myself by thinking you were still refering
to your comments 2004-03-29 comparing DateFilter with RangeQuery wrapped
in a QueryFilter.
: I debate (with myself) on whether add-ons that can be done with other
: code is worth adding to Lucene's core. In this case the utility
: methods are so commonly needed that it makes sense. But it could be
In particular, having a class of utilities like that in the code base is
usefull, because now the javadocs for classes like RangeQuery and
RangeFilter can refrence them as being neccessary important to ensure that
ranges work the way you expect ... and hopefully fewer people will be
confused in the future.
: I think there needs to be some discussion on what other utility methods
: should be added. For example, most of the numerics I index are
: positive integers and using a zero-padded is sufficient. I'd rather
: have clearly recognizable numbers in my fields than some strange
: contortion that requires a conversion process to see.
I'm of two minds, on one hand I think there's no big harm in providing
every concievable utility function known to man so people have their
choice of representation. On the other hand, I think it would be nice if
Lucene had a much simpler API for dealing with "non-strings" that just did
"the right thing" based on simple expectations -- without the user having
to ask themselves: "Will i ever need negative numbers? Will I ever need
numbers bigger then 1000?" or to later remember that they padded tis field
to 5 digits and that field to 7 digits.
Having clearly recognized values is something that can (should?) be easily
accomplished by indexing the contorted but lexically sortable value, and
storing the more readable value...
Document d = /* some doc */;
Long l = /* some value */;
Field f1 = Field.UnIndexed("field", l.toString());
Field f2 = Field.UnStored("field", NumerTools.longToString(l));
d.add(f1);
d.add(f2);
(I'm not imagining things right? that should work, correct?)
What would really be sweet, Is if Lucene had an API that
transparently dealt with all of the major primitive types, both at
indexing time and at query time, so that users ddn't have to pay any
attention to the stringification, or when to Index a different value
then they store...
Field f = Field.Long("field", l); /* indexes one string, stores the other */
d.add(f);
...
Query q = new RangeQuery("field", l1, l2); /* knows to use the contorted
string */
...
String s = hits.doc(i).getValue("field"); /* returns pretty string */
Long l = hits.doc(i).getValue("field"); /* returns orriginal Long */
--
-------------------------------------------------------------------
"Oh, you're a tricky one." Chris M Hostetter
-- Trisha Weir [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
