On Friday 15 April 2005 01:46, Chris Hostetter wrote:
> Or worse, a query that does work today, stops working tomorow because
> one doc was removed.
You're right, that is not acceptable. I've created a bug report about the
original problem:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34477
: one is sorting on doesn't even have to exist in all the documents. I
: think it would be even more confusing for an invalid query suddenly
: becoming a valid query in the future just because someone added a doc
Or worse, a query that does work today, stops working tomorow because one
doc was r
Also, it's more flexible. You can easily implement stricter checking
on top of a "lax" model (use a term enumerator to see if the field
exists before you call search), but not vice versa.
-Yonik
On 4/14/05, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> Hmmm, that's a great lucene architecture questi
Hmmm, that's a great lucene architecture question.
Should one be allowed to sort on a field that doesn't exist?
One *can* query on fields that don't exist (and that's correct in my view).
The thing is, lucene field creation is lazy... just because the field
doesn't exist now doesn't mean that it w
On Thursday 14 April 2005 16:28, Yonik Seeley wrote:
> I haven't tried it, but I think the fix should be easy... never throw
> that exception.
As Lucene does not have the concept of a "warning" I think it should throw
exceptions when someone tries to do something that doesn't make sense
(even i
> if (termEnum==null || term.field() != field) break; // CHANGE
> here
Errr, that should be term==null of course.
> if (term==null || term.field() != field) break; // CHANGE here
And it *may* be slightly speedier to check for null just before the
do/while loop instead:
I haven't tried it, but I think the fix should be easy... never throw
that exception. Either check for null before the loop, or in the
loop.
Original code for native int sorting:
TermEnum termEnum = reader.terms (new Term (field, ""));
try {
if (termEnum.term() == null)
On Tuesday 12 April 2005 20:04, Bill Tschumy wrote:
> Here is a small program that will manifest the error. ÂHopefully Â
> someone can explain the problem. ÂIt happens with Lucene 1.4.2 and Â
> 1.4.3.
This is the code that throws the exception (from FieldCacheImpl.java):
TermEnum termEnum = re
Great! Thanks for looking at it and thanks for the work around.
On Apr 12, 2005, at 1:50 PM, Yonik Seeley wrote:
A workaround until this problem is fixed in Lucene would be to add an
indexed sentinel field to a single doc in the collection that will be
larger (after) all other fields that you may
A workaround until this problem is fixed in Lucene would be to add an
indexed sentinel field to a single doc in the collection that will be
larger (after) all other fields that you may try a sort on.
Example:
String sentinel = new String(new char[]{0x});
doc.add(Field.
> Any fieldName that starts with "i" or
> below (including capitals) works. Can anyone think of what could
> possibly be going on here?
Looks like you uncovered an obscure sorting bug.
The reason that fields >= "j" fail is that your last indexed field
(and hence the last indexed term) starts w
On Apr 12, 2005, at 8:38 AM, Erik Hatcher wrote:
Could you give us a self-contained test case that reproduces this
issue?
Erik
Here is a small program that will manifest the error. Hopefully
someone can explain the problem. It happens with Lucene 1.4.2 and
1.4.3.
file: SortProblem
Could you give us a self-contained test case that reproduces this issue?
Erik
On Apr 12, 2005, at 9:19 AM, Bill Tschumy wrote:
This problem is seeming more and more strange. It now looks like if
the fieldName I'm sorting on starts is ASCII "j" or above, the
RuntimeException is thrown.
This problem is seeming more and more strange. It now looks like if
the fieldName I'm sorting on starts is ASCII "j" or above, the
RuntimeException is thrown. Any fieldName that starts with "i" or
below (including capitals) works. Can anyone think of what could
possibly be going on here?
In my application, by default I display all documents that are in the
index. I sort them either using a "time modified" or "time created".
If I have a newly created empty index, I find I get an error if I sort
by "time modified" but not "time created". In either case there are
actually n
15 matches
Mail list logo
