Rus,
Yes - the sorting custom comparator was only set up to use
Comparable.compareTo() - it can't really compare native types using < or >.
I think your best bet might be to encode your dates at index time into
integers and put those in the index (assuming you really need Dates and not
Timestam
Guys,
I'm going to be out of town almost all next week, and won't get a chance to
look at this until the week after. If anyone wants to work on it before
then, feel free.
btw, it's nice to be back after a hiatus :) I took a detour out of the
tech world for the past few months, but am back now
I don't really need any geographical scoring. I just need to be able
to show all items within a region. Since a lot of the complexity of
"Query" has to do with scoring, would it be better to just use the
GeoFilter, and to search for *? Are there any performance issues
with this?
You might try
+1
like the idea!
Attached is a patch that makes it possible to supply a user-specified
parser to FieldCache. For example, one might use this to process a date
field as ints even if was not indexed as a decimal integer.
Comments?
Doug
--
+1
I'd like to propose Wolfgang Hoschek should be given commit rights to
maintain his MemoryIndex contribution.
Thoughts?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Doug,
How will the difference impact String memory allocations? Looking at the
String code, I can't see where it would make an impact.
Tim
I would argue that the length written be the number of characters in the
string, rather than the number of bytes written, since that can minimize
stri
