Re: 1.4.3 breaks 1.4.1 QueryParser functionality
> > Is this workable for you, Bill? > > No, it doesn't appear to work for me. Whoops! I was testing the wrong jar file. Yes, it *does* appear to work for me. I'll put this in my production code. Thanks again, Erik. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
Erik,
> Is this workable for you, Bill?
No, it doesn't appear to work for me.
I modified my class to add the extra method, as you suggested. I just
forwarded the method to the existing one, as seen below:
protected Query getFieldQuery (String field,
Analyzer a,
String queryText,
int slop)
throws ParseException {
return getFieldQuery(field, a, queryText);
}
protected Query getFieldQuery (String field,
Analyzer a,
String queryText)
throws ParseException {
...
}
It's still not getting called. My query string is of the form:
name:"Bill Janssen"
which is a little different from the one you were testing with. It
does work OK (with both versions of Lucene) on simple queries like the
one you tested with.
My guess is that somewhere between 1.4.1 and 1.4.3, someone decided
that FieldQueries and PhraseQueries should be handled differently.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
On Jan 5, 2005, at 5:04 AM, Erik Hatcher wrote:
On Jan 4, 2005, at 9:43 PM, Bill Janssen wrote:
Let me be a bit more explicit. My method (essentially an
after-method, for those Lisp'rs out there) begins thusly:
protected Query getFieldQuery (String field,
Analyzer a,
String queryText)
throws ParseException {
Query x = super.getFieldQuery(field, a, queryText);
...
}
If I remove the "Analyzer a" from both the signature and the super
call, the super call won't compile because that method isn't in the
QueryParser in 1.4.1. But my getFieldQuery() method won't even be
called in 1.4.1, because it doesn't exist in that version of the
QueryParser.
Will it work if you override this method also?
protected Query getFieldQuery(String field,
Analyzer analyzer,
String queryText,
int slop)
My head is spinning looking at all the various signatures of this
method we have and trying to backtrack where things went awry.
I tried out my suggestion (code pasted below) against
lucene-1.4-final.jar and lucene-1.4-3.jar (I don't have the 1.4.1 JAR
handy) and was successful. If you override both signatures of
getFieldQuery it should work fine for you across all 1.4.x versions.
Not ideal, but at least a workaround.
Is this workable for you, Bill?
Erik
public class CustomQueryParser extends QueryParser {
public CustomQueryParser(String field, Analyzer analyzer) {
super(field, analyzer);
}
protected Query getFieldQuery(String field, Analyzer analyzer,
String queryText, int slop) throws ParseException {
System.out.println("(slop) queryText = " + queryText);
return null;
}
protected Query getFieldQuery (String field,
Analyzer a,
String queryText)
throws ParseException {
System.out.println("(no-slop) queryText = " + queryText);
return null;
}
public static void main(String[] args) throws Exception {
CustomQueryParser qp = new CustomQueryParser("f", new
WhitespaceAnalyzer());
qp.parse("foo bar");
qp.parse("\"foo bar\"");
}
}
The output was identical with both versions of Lucene:
(no-slop) queryText = foo
(no-slop) queryText = bar
(slop) queryText = foo bar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
> On Jan 5, 2005, at 3:46 PM, Bill Janssen wrote: > > Maybe I just misunderstand your release numbering policy. Typically, > > in a library project that has major, minor, and micro release numbers, > > I'd expect no API changes between micro releases of a single minor > > release; only backward-compatible API extensions between different > > minor releases of a single major release; possible wholesale API > > changes (not backward compatible) between different major releases. > > Is this the kind of thinking that you also have? > > Yes, absolutely. The flaw you have stumbled on was completely an > oversight and a mistake that should not have occurred. I, for one, > apologize for not catching it. Only because I have custom QueryParser > subclasses and lots of unit tests did I catch the signature changes > that I did, and I'm not sure how I missed this one. I have not gone > back, yet, to review the change history and whether my code is broken > in one of those versions of Lucene, or whether I've not overridden that > method. OK, then it's just a bug, and we all make bugs (me probably more than you, at that). Thanks for all your help with this, Erik. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
Hello Bill, "I feel your pain" ;) But seriously, there was a QueryParser mess-up in the recent minor releases. I think this is the first time we've messed up the backward compatibility in the last ~4 years, I believe. Lucene public API is very 'narrow', and typically very stable. What we did with QueryParser was the result of 'overeagerness', but is really out of character for Lucene. Otis --- Bill Janssen <[EMAIL PROTECTED]> wrote: > Doug, > > My application (see http://www.parc.com/janssen/pubs/TR-03-16.pdf for > details) is not just a Java app (you're probably not surprised :-). > It requires about a dozen other packages to be installed on a > machine, > before building from source. The Python Imaging Library, ReportLab, > libtiff, libpng, xpdf, htmldoc, etc. Lucene is one of these > prerequisites. I don't include any other outside code with my tar > file; not sure why Lucene should be the only one to require this. > > Besides, I'd like to keep up with the continuous improvements in > Lucene. I don't want to be stuck with 1.4.1 forever. > > Please understand that I'm not trying to push your project in any > particular direction. I'm just trying to understand whether Lucene > is > usable for my project. If every micro-release of Lucene means that I > will potentially have to re-write my code, I may have to look for a > library with a more stable API. > > Maybe I just misunderstand your release numbering policy. Typically, > in a library project that has major, minor, and micro release > numbers, > I'd expect no API changes between micro releases of a single minor > release; only backward-compatible API extensions between different > minor releases of a single major release; possible wholesale API > changes (not backward compatible) between different major releases. > Is this the kind of thinking that you also have? > > I can certainly understand that when you find improvements you'd like > to make in the API, you'd want to put them in. I just think it's > important not to break existing code without bumping the release > number, so that a user can say, "This works with Lucene 1.4". Right > now, that can't be said. > > Bill > > Doug Cutting wrote: > > Bill, most folks bundle appropriate versions of required jars with > their > > applications to avoid this sort of problem. How are you deploying > > things? Are you not bundling a compatible version of the lucene > jar > > with each release of your application? If not, why not? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
On Jan 5, 2005, at 3:46 PM, Bill Janssen wrote: Maybe I just misunderstand your release numbering policy. Typically, in a library project that has major, minor, and micro release numbers, I'd expect no API changes between micro releases of a single minor release; only backward-compatible API extensions between different minor releases of a single major release; possible wholesale API changes (not backward compatible) between different major releases. Is this the kind of thinking that you also have? Yes, absolutely. The flaw you have stumbled on was completely an oversight and a mistake that should not have occurred. I, for one, apologize for not catching it. Only because I have custom QueryParser subclasses and lots of unit tests did I catch the signature changes that I did, and I'm not sure how I missed this one. I have not gone back, yet, to review the change history and whether my code is broken in one of those versions of Lucene, or whether I've not overridden that method. In short - we screwed up, and we should fix it since its obviously important to you. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
On Jan 5, 2005, at 3:48 PM, Bill Janssen wrote:
In 1.4.1 or 1.4.3?
Both - my suggestion was an attempt to get you something that would
work in both versions.
Erik
On Jan 4, 2005, at 9:43 PM, Bill Janssen wrote:
Let me be a bit more explicit. My method (essentially an
after-method, for those Lisp'rs out there) begins thusly:
protected Query getFieldQuery (String field,
Analyzer a,
String queryText)
throws ParseException {
Query x = super.getFieldQuery(field, a, queryText);
...
}
If I remove the "Analyzer a" from both the signature and the super
call, the super call won't compile because that method isn't in the
QueryParser in 1.4.1. But my getFieldQuery() method won't even be
called in 1.4.1, because it doesn't exist in that version of the
QueryParser.
Will it work if you override this method also?
protected Query getFieldQuery(String field,
Analyzer analyzer,
String queryText,
int slop)
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
In 1.4.1 or 1.4.3?
> On Jan 4, 2005, at 9:43 PM, Bill Janssen wrote:
> > Let me be a bit more explicit. My method (essentially an
> > after-method, for those Lisp'rs out there) begins thusly:
> >
> > protected Query getFieldQuery (String field,
> >Analyzer a,
> >String queryText)
> > throws ParseException {
> >
> > Query x = super.getFieldQuery(field, a, queryText);
> >
> > ...
> > }
> >
> > If I remove the "Analyzer a" from both the signature and the super
> > call, the super call won't compile because that method isn't in the
> > QueryParser in 1.4.1. But my getFieldQuery() method won't even be
> > called in 1.4.1, because it doesn't exist in that version of the
> > QueryParser.
>
> Will it work if you override this method also?
>
> protected Query getFieldQuery(String field,
>Analyzer analyzer,
>String queryText,
>int slop)
>
> Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
Doug, My application (see http://www.parc.com/janssen/pubs/TR-03-16.pdf for details) is not just a Java app (you're probably not surprised :-). It requires about a dozen other packages to be installed on a machine, before building from source. The Python Imaging Library, ReportLab, libtiff, libpng, xpdf, htmldoc, etc. Lucene is one of these prerequisites. I don't include any other outside code with my tar file; not sure why Lucene should be the only one to require this. Besides, I'd like to keep up with the continuous improvements in Lucene. I don't want to be stuck with 1.4.1 forever. Please understand that I'm not trying to push your project in any particular direction. I'm just trying to understand whether Lucene is usable for my project. If every micro-release of Lucene means that I will potentially have to re-write my code, I may have to look for a library with a more stable API. Maybe I just misunderstand your release numbering policy. Typically, in a library project that has major, minor, and micro release numbers, I'd expect no API changes between micro releases of a single minor release; only backward-compatible API extensions between different minor releases of a single major release; possible wholesale API changes (not backward compatible) between different major releases. Is this the kind of thinking that you also have? I can certainly understand that when you find improvements you'd like to make in the API, you'd want to put them in. I just think it's important not to break existing code without bumping the release number, so that a user can say, "This works with Lucene 1.4". Right now, that can't be said. Bill Doug Cutting wrote: > Bill, most folks bundle appropriate versions of required jars with their > applications to avoid this sort of problem. How are you deploying > things? Are you not bundling a compatible version of the lucene jar > with each release of your application? If not, why not? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
Bill Janssen wrote: 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, most folks bundle appropriate versions of required jars with their applications to avoid this sort of problem. How are you deploying things? Are you not bundling a compatible version of the lucene jar with each release of your application? If not, why not? I'm not trying to be difficult, just trying to understand. Thanks, Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
On Jan 4, 2005, at 9:43 PM, Bill Janssen wrote:
Let me be a bit more explicit. My method (essentially an
after-method, for those Lisp'rs out there) begins thusly:
protected Query getFieldQuery (String field,
Analyzer a,
String queryText)
throws ParseException {
Query x = super.getFieldQuery(field, a, queryText);
...
}
If I remove the "Analyzer a" from both the signature and the super
call, the super call won't compile because that method isn't in the
QueryParser in 1.4.1. But my getFieldQuery() method won't even be
called in 1.4.1, because it doesn't exist in that version of the
QueryParser.
Will it work if you override this method also?
protected Query getFieldQuery(String field,
Analyzer analyzer,
String queryText,
int slop)
My head is spinning looking at all the various signatures of this
method we have and trying to backtrack where things went awry.
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
> > 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 method (essentially an
after-method, for those Lisp'rs out there) begins thusly:
protected Query getFieldQuery (String field,
Analyzer a,
String queryText)
throws ParseException {
Query x = super.getFieldQuery(field, a, queryText);
...
}
If I remove the "Analyzer a" from both the signature and the super
call, the super call won't compile because that method isn't in the
QueryParser in 1.4.1. But my getFieldQuery() method won't even be
called in 1.4.1, because it doesn't exist in that version of the
QueryParser.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
> 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 micro-release of Lucene (which, you might guess, I don't). That signature doesn't compile with 1.4.1. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
On Tuesday 04 January 2005 23:53, Bill Janssen wrote: > Â Â protected Query getFieldQuery (String field, > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ÂAnalyzer a, > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ÂString queryText) > Â Â Â Â throws ParseException 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. Regards Daniel -- http://www.danielnaber.de
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
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 with a query string of the form field:"text1 text2" Bill > What getFieldQuery signature are you overriding? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.4.3 breaks 1.4.1 QueryParser functionality
Bill, If we broken API compatibility then we screwed up. What getFieldQuery signature are you overriding? As for version numbers - there are no strict conventions. The API should not have broken in 1.4.2, nor in 1.4.3 - this is very unfortunate. I caught what I thought were all of the incompatibilities introduced in 1.4.2, but apparently I missed something that perhaps my test cases didn't account for? Erik On Jan 4, 2005, at 1:13 PM, Bill Janssen wrote: 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 instance, with 1.4.1, when I use the query string category:"user names" during the parsing of the query, the method "getFieldQuery" is called, which allows me to do some custom analysis of the search terms, for particular field names. However, with 1.4.3, "getFieldQuery" is *not* called. Why not? Is something else called instead? Also, what's the difference between major, minor, and micro release numbers in the context of the Lucene project? I'm still stuck on 1.4.1 due to these incompatibilities. I'm a bit surprised that differences between two micro releases of the same minor release would cause this much difficulty. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.4.3 breaks 1.4.1 QueryParser functionality
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 instance, with 1.4.1, when I use the query string category:"user names" during the parsing of the query, the method "getFieldQuery" is called, which allows me to do some custom analysis of the search terms, for particular field names. However, with 1.4.3, "getFieldQuery" is *not* called. Why not? Is something else called instead? Also, what's the difference between major, minor, and micro release numbers in the context of the Lucene project? I'm still stuck on 1.4.1 due to these incompatibilities. I'm a bit surprised that differences between two micro releases of the same minor release would cause this much difficulty. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
