Hi.
I've got a Lucene application that's been in use for about two years.
Some users are using Lucene 1.2, some 1.3, and some are moving to 1.4.
The indices seem to behave differently under each version. I'd like
to add code to my application that checks the current user's index
version against
Thanks, Doug, much as I'd figured from looking at the code.
Here's a follow-up question: Is there any programmatic way to tell
which version of the Lucene code a program is using? A version number
or string would be great (perhaps an idea for the next release), but a
list of classes in one
Hi!
I'm using Lucene for an application which has lots of fields/document,
in which the users can specify in their config files what fields they
wish to be included by default in a search. I'd been happily using
MultiFieldQueryParser to do the searches, but the darn users started
demanding more
René,
Thanks for your note.
I'd think that if a user specified a query cutting lucene, with an
implicit AND and the default fields title and author, they'd
expect to see a match in which both cutting and lucene appears. That is,
(title:cutting OR author:cutting) AND (title:lucene OR
is it a problem if the users will search coffee OR tea as a search
string in the case that MultifieldQueryParser is
modifyed as Bill suggested?, and the default opperator is set to AND?
Here's what you get (which is correct):
% java -classpath /usr/local/lib/lucene-1.4.1.jar:. \
But, inspired by that message, couldn't MultiFieldQueryParser just be a
subclass of QueryParser that overrides getFieldQuery()?
I wasn't sure that everything went through getFieldQuery(). If so,
yes, that should work. In either case, I don't even think a subclass
is necessary. Just have a
Doug Cutting writes:
http://issues.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1798116
Yes, the approach there is similar. I attempted to complete the
solution and provide a working replacement for MultiFieldQueryParser.
But, inspired by that message, couldn't MultiFieldQueryParser
Bill Tschumy writes:
I've looked at pdfBox, but the jar file is so big that I
hate to burden my users by incorporating it.
Bill,
My system (see http://www.parc.com/janssen/pubs/TR-03-16.pdf) uses
pdftotext underneath. I've been very satisfied with that. Another
Java solution would be to use
I'm not sure this solution is very robust
Thanks, but I'm pretty sure it *is* robust. Can you please offer a
specific critique? Always happy to learn and improve :-).
I think I already sent an email with a better code...
Pretty vague. Can you send a URL for that message in the
Try to see the behavior if you want to have a single term query
juat something like: robust .. and print out the query string ...
Sure, that works fine. For instance, if you have the three default
fields title, authors, and contents, the one-word search
robust expands to
title:foobar
Strange .. on my computer was created just someting like
default:foobar
... and I think that should work like that on your computer too ... I've
take a look on lucene code ... and I undestood why ...
all the best ... Sergiu
So, why?
Try running the program at
wouldn't it be better to go on and overwrite the methods creating these
types of queries too?
There's no need to. My existing code works just fine with them. For
instance, if you put in the query foo*, with the default fields
title, authors, and contents, you get the expanded query
I know, I know, it's bad form to answer your own question. But here's
a test program to distinguish between Lucene 1.4.1 and 1.4.2.
Bill
import java.io.*;
import java.lang.Class;
import java.lang.reflect.Method;
class testLucene {
private static boolean compareArgs (Class[] args1,
is +(title:gut* authors:gut* contents:gut*) +(title:test authors:test
contents:test)
%
This is the old version that doesn't implement getFieldQuery().
Bill
On Friday 29 October 2004 20:42, Bill Janssen wrote:
Try running the program at
ftp://ftp.parc.xerox.com/transient/janssen
I'm trying to figure out what changed between 1.4.1 and 1.4.3 to break
my application. I couldn't use 1.4.2, because my app wouldn't compile
with 1.4.2, due to API changes. With 1.4.3, the API incompatibilities
were fixed, but now the QueryParser seems to process query strings
differently.
For
Erik,
The signature I'm overriding is
protected Query getFieldQuery (String field,
Analyzer a,
String queryText)
throws ParseException
It gets called with a query string of the form
field:text
but no longer
You're right, the problem is that we should call the deprecated method for
example in getFieldQuery(String field, String queryText, int slop).
However, there's a simple workaround: just remove the analyzer parameter
from your method.
Sure, if I wanted to ship different code for each
However, there's a simple workaround: just remove the analyzer parameter
from your method.
Sure, if I wanted to ship different code for each micro-release of
Lucene (which, you might guess, I don't). That signature doesn't
compile with 1.4.1.
Bill
Let me be a bit more explicit. My
18 matches
Mail list logo
