Bill Janssen <[EMAIL PROTECTED]> wrote:

> I'm seeing parse failures on this query string:
>
> "categories:RSSReader AND id:[00000-00-0000-000 TO 01299-51-3142-795] AND NOT categories:RSSReader/_noexpire_"

3.0.3 works just fine.

Bill

  Hi Bill,

The QueryParser class changed a bit. More overloads were introduced on the
Lucene side. You probably have a Python 'subclass' of QueryParser that needs
a bit of work to adapt to the changes.

Look at the new version in
apache/pylucene-3.1/java/org/apache/pylucene/queryParser/PythonQueryParser.java
and see the native methods that you're missing on your Python
implementation. Also take a look at test/test_PythonQueryParser.py for an
example on what the new methods look like (hint: getFieldQuery_quoted()).

With a default QueryParser instance, your query parses just fine:

   >>> from lucene import *
   >>> initVM()
   <jcc.JCCEnv object at 0x10029d0f0>
   >>> qp = QueryParser(Version.LUCENE_CURRENT, "foo", StandardAnalyzer(Version.LUCENE_CURRENT))
   >>> qp.parse("categories:RSSReader AND id:[00000-00-0000-000 TO 01299-51-3142-795] AND NOT categories:RSSReader/_noexpire_")
   <Query: +categories:rssreader +id:[00000-00-0000-000 TO 01299-51-3142-795] -(categories:rssreader categories:_noexpire_)>

Andi..

On Wed, 6 Apr 2011, Bill Janssen wrote:

> I'm seeing parse failures on this query string:
>
> "categories:RSSReader AND id:[00000-00-0000-000 TO 01299-51-3142-795] AND NOT categories:RSSReader/_noexpire_"
>
> thr002: RSSReader:  Traceback (most recent call last):
> thr002:   File "/local/lib/UpLib-1.7.11/site-extensions/RSSReader.py", line 271, in _scan_rss_sites
> thr002:     hits = repo.do_query("categories:RSSReader AND id:[00000-00-0000-000 TO %s] AND NOT categories:RSSReader/_noexpire_" % old_id)
> thr002:   File "/local/share/UpLib-1.7.11/code/uplib/repository.py", line 1172, in do_query
> thr002:     results = self.do_full_query(query_string, searchtype)
> thr002:   File "/local/share/UpLib-1.7.11/code/uplib/repository.py", line 1196, in do_full_query
> thr002:     results = self.pylucene_search(searchtype, query_string)
> thr002:   File "/local/share/UpLib-1.7.11/code/uplib/repository.py", line 1081, in pylucene_search
> thr002:     v = self.__search_context.search(query_string)
> thr002:   File "/local/share/UpLib-1.7.11/code/uplib/indexing.py", line 913, in search
> thr002:     parsed_query = query_parser.parseQ(query)
> thr002:   File "/local/share/UpLib-1.7.11/code/uplib/indexing.py", line 550, in parseQ
> thr002:     query = QueryParser.parse(self, querystring)
> thr002: JavaError: org.apache.jcc.PythonException: getFieldQuery_quoted
> thr002: AttributeError: getFieldQuery_quoted
>
> thr002:     Java stacktrace:
> thr002: org.apache.jcc.PythonException: getFieldQuery_quoted
> thr002: AttributeError: getFieldQuery_quoted
>
> thr002: at org.apache.pylucene.queryParser.PythonMultiFieldQueryParser.getFieldQuery_quoted(Native Method)
> thr002: at org.apache.pylucene.queryParser.PythonMultiFieldQueryParser.getFieldQuery(Unknown Source)
> thr002: at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1421)
> thr002: at org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1309)
> thr002: at org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1237)
> thr002: at org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1226)
> thr002: at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206)
>
>
> Bill
>

Andi Vajda <[EMAIL PROTECTED]> wrote:

>
>  Hi Bill,
>
> The QueryParser class changed a bit. More overloads were introduced on
> the Lucene side. You probably have a Python 'subclass' of QueryParser
> that needs a bit of work to adapt to the changes.

Thanks, but...   All that adds up to breakage for my users.

Bill

On Wed, 6 Apr 2011, Bill Janssen wrote:

> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>
>>  Hi Bill,
>>
>> The QueryParser class changed a bit. More overloads were introduced on
>> the Lucene side. You probably have a Python 'subclass' of QueryParser
>> that needs a bit of work to adapt to the changes.
>
> Thanks, but...   All that adds up to breakage for my users.

Unless I'm missing something here, you've got two options before you break
your users:
   1. fix your code before you ship it to them
   2. don't upgrade

Yes, you could say that the same applies to PyLucene, of course :-)

I'm not exactly sure what kind of backwards compat promises Lucene Java made
going from 3.0 to 3.1 but the new QueryParser method overloads and the fact
that there is no support for method overloads in Python make
PythonQueryParser a bit stuck between a rock and a hard place. If you see a
better way to fix the mess with the _quoted and _slop variants for
getFieldQuery, a patch is welcome.

Andi..

Andi Vajda <[EMAIL PROTECTED]> wrote:

> Unless I'm missing something here, you've got two options before you
> break your users:
>   1. fix your code before you ship it to them

Unfortunately, the code is out there for building, and the instructions,
also already out there, say, "PyLucene 2.4 to 3.X".  I should be more
careful :-).

>   2. don't upgrade

It's the users that upgrade, not me.

> Yes, you could say that the same applies to PyLucene, of course :-)

:-)

> I'm not exactly sure what kind of backwards compat promises Lucene
> Java made going from 3.0 to 3.1 but the new QueryParser method
> overloads and the fact that there is no support for method overloads
> in Python make PythonQueryParser a bit stuck between a rock and a hard
> place. If you see a better way to fix the mess with the _quoted and
> _slop variants for getFieldQuery, a patch is welcome.

Sure.

Bill

On Wed, 6 Apr 2011, Bill Janssen wrote:

> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>> Unless I'm missing something here, you've got two options before you
>> break your users:
>>   1. fix your code before you ship it to them
>
> Unfortunately, the code is out there for building, and the instructions,
> also already out there, say, "PyLucene 2.4 to 3.X".  I should be more
> careful :-).

Given that APIs changed quite a bit between 2.x and 3.0 and that
2.x deprecated APIs are removed from 3.1+ (unless I'm confused about
Lucene's deprecation policy (*)), your statement is a bit optimistic.

(*) maybe it's not until 4.0 that they're going to be removed ? I can't
     remember at the moment. Mike, if you read this, can you please correct
     me if I'm wrong ?

Andi..

>
>>   2. don't upgrade
>
> It's the users that upgrade, not me.
>
>> Yes, you could say that the same applies to PyLucene, of course :-)
>
> :-)
>
>> I'm not exactly sure what kind of backwards compat promises Lucene
>> Java made going from 3.0 to 3.1 but the new QueryParser method
>> overloads and the fact that there is no support for method overloads
>> in Python make PythonQueryParser a bit stuck between a rock and a hard
>> place. If you see a better way to fix the mess with the _quoted and
>> _slop variants for getFieldQuery, a patch is welcome.
>
> Sure.
>
> Bill
>

On Wed, Apr 6, 2011 at 6:38 PM, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Wed, 6 Apr 2011, Bill Janssen wrote:
>
>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>
>>> Unless I'm missing something here, you've got two options before you
>>> break your users:
>>>  1. fix your code before you ship it to them
>>
>> Unfortunately, the code is out there for building, and the instructions,
>> also already out there, say, "PyLucene 2.4 to 3.X".  I should be more
>> careful :-).
>
> Given that APIs changed quite a bit between 2.x and 3.0 and that 2.x
> deprecated APIs are removed from 3.1+ (unless I'm confused about Lucene's
> deprecation policy (*)), your statement is a bit optimistic.
>
> (*) maybe it's not until 4.0 that they're going to be removed ? I can't
>    remember at the moment. Mike, if you read this, can you please correct
>    me if I'm wrong ?

Actually, any API deprecated in any Lucene 2.x release is removed in
3.0.  (Same for 3.x to 4.0, etc.).

Mike

http://blog.mikemccandless.com

On Wed, 6 Apr 2011, Michael McCandless wrote:

> On Wed, Apr 6, 2011 at 6:38 PM, Andi Vajda <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, 6 Apr 2011, Bill Janssen wrote:
>>
>>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>>
>>>> Unless I'm missing something here, you've got two options before you
>>>> break your users:
>>>> �1. fix your code before you ship it to them
>>>
>>> Unfortunately, the code is out there for building, and the instructions,
>>> also already out there, say, "PyLucene 2.4 to 3.X". �I should be more
>>> careful :-).
>>
>> Given that APIs changed quite a bit between 2.x and 3.0 and that 2.x
>> deprecated APIs are removed from 3.1+ (unless I'm confused about Lucene's
>> deprecation policy (*)), your statement is a bit optimistic.
>>
>> (*) maybe it's not until 4.0 that they're going to be removed ? I can't
>> � �remember at the moment. Mike, if you read this, can you please correct
>> � �me if I'm wrong ?
>
> Actually, any API deprecated in any Lucene 2.x release is removed in
> 3.0.  (Same for 3.x to 4.0, etc.).

Ah, I thought 3.0 had them both. Ok, duly noted.
Thanks !

Andi..

Andi Vajda <[EMAIL PROTECTED]> wrote:

>
> On Wed, 6 Apr 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> wrote:
> >
> >> Unless I'm missing something here, you've got two options before you
> >> break your users:
> >>   1. fix your code before you ship it to them
> >
> > Unfortunately, the code is out there for building, and the instructions,
> > also already out there, say, "PyLucene 2.4 to 3.X".  I should be more
> > careful :-).
>
> Given that APIs changed quite a bit between 2.x and 3.0 and that 2.x
> deprecated APIs are removed from 3.1+ (unless I'm confused about
> Lucene's deprecation policy (*)), your statement is a bit optimistic.

My Python code looks for the differences and handles it.  Of course, it
can't do that for the future :-).

Is there some ABI version # that I should be checking, instead?

Bill

On Wed, 6 Apr 2011, Bill Janssen wrote:

> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>
>> On Wed, 6 Apr 2011, Bill Janssen wrote:
>>
>>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>>
>>>> Unless I'm missing something here, you've got two options before you
>>>> break your users:
>>>>   1. fix your code before you ship it to them
>>>
>>> Unfortunately, the code is out there for building, and the instructions,
>>> also already out there, say, "PyLucene 2.4 to 3.X".  I should be more
>>> careful :-).
>>
>> Given that APIs changed quite a bit between 2.x and 3.0 and that 2.x
>> deprecated APIs are removed from 3.1+ (unless I'm confused about
>> Lucene's deprecation policy (*)), your statement is a bit optimistic.
>
> My Python code looks for the differences and handles it.  Of course, it
> can't do that for the future :-).
>
> Is there some ABI version # that I should be checking, instead?

There are two versions available from the lucene module:

    >>> import lucene
    >>> [(v, lucene.__dict__[v]) for v in dir(lucene) if 'VERSION' in v]
    [('JCC_VERSION', '2.8'), ('VERSION', '3.1.0')]

There is also the lucene.Version object.

Andi..

Andi Vajda <[EMAIL PROTECTED]> wrote:

> There are two versions available from the lucene module:
>
>    >>> import lucene
>    >>> [(v, lucene.__dict__[v]) for v in dir(lucene) if 'VERSION' in v]
>    [('JCC_VERSION', '2.8'), ('VERSION', '3.1.0')]

I suppose I could make a list of all the (JCC_VERSION, VERSION) pairs
that I've personally verified that the code works with, and raise an error
if a user attempts to install UpLib using a PyLucene that isn't on that
list...  But that seems like a sub-optimal solution :-).

Bill

On Wed, 6 Apr 2011, Bill Janssen wrote:

> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>> There are two versions available from the lucene module:
>>
>>   >>> import lucene
>>   >>> [(v, lucene.__dict__[v]) for v in dir(lucene) if 'VERSION' in v]
>>    [('JCC_VERSION', '2.8'), ('VERSION', '3.1.0')]
>
> I suppose I could make a list of all the (JCC_VERSION, VERSION) pairs
> that I've personally verified that the code works with, and raise an error
> if a user attempts to install UpLib using a PyLucene that isn't on that
> list...  But that seems like a sub-optimal solution :-).

Seems like the best solution to me.
How can you be sure your code works otherwise ?

Andi..

Andi Vajda <[EMAIL PROTECTED]> wrote:

> Look at the new version in
> apache/pylucene-3.1/java/org/apache/pylucene/queryParser/PythonQueryParser.java
> and see the native methods that you're missing on your Python

Wow, looks like a lot.  My implementations just have implementations of
getFieldQuery() and getRangeQuery().

> implementation. Also take a look at test/test_PythonQueryParser.py for
> an example on what the new methods look like (hint:
> getFieldQuery_quoted()).

Looking at that, it seems that one needn't provide implementations for
most of the native methods -- your example classes don't.  How should one
know which to implement?  The ones that could get called, I suppose.

Bill
>
> With a default QueryParser instance, your query parses just fine:
>
>   >>> from lucene import *
>   >>> initVM()
>   <jcc.JCCEnv object at 0x10029d0f0>
>   >>> qp = QueryParser(Version.LUCENE_CURRENT, "foo", StandardAnalyzer(Version.LUCENE_CURRENT))
>   >>> qp.parse("categories:RSSReader AND id:[00000-00-0000-000 TO 01299-51-3142-795] AND NOT categories:RSSReader/_noexpire_")
>   <Query: +categories:rssreader +id:[00000-00-0000-000 TO 01299-51-3142-795] -(categories:rssreader categories:_noexpire_)>
>
> Andi..
>
> On Wed, 6 Apr 2011, Bill Janssen wrote:
>
> > I'm seeing parse failures on this query string:
> >
> > "categories:RSSReader AND id:[00000-00-0000-000 TO 01299-51-3142-795] AND NOT categories:RSSReader/_noexpire_"
> >
> > thr002: RSSReader:  Traceback (most recent call last):
> > thr002:   File "/local/lib/UpLib-1.7.11/site-extensions/RSSReader.py", line 271, in _scan_rss_sites
> > thr002:     hits = repo.do_query("categories:RSSReader AND id:[00000-00-0000-000 TO %s] AND NOT categories:RSSReader/_noexpire_" % old_id)
> > thr002:   File "/local/share/UpLib-1.7.11/code/uplib/repository.py", line 1172, in do_query
> > thr002:     results = self.do_full_query(query_string, searchtype)
> > thr002:   File "/local/share/UpLib-1.7.11/code/uplib/repository.py", line 1196, in do_full_query
> > thr002:     results = self.pylucene_search(searchtype, query_string)
> > thr002:   File "/local/share/UpLib-1.7.11/code/uplib/repository.py", line 1081, in pylucene_search
> > thr002:     v = self.__search_context.search(query_string)
> > thr002:   File "/local/share/UpLib-1.7.11/code/uplib/indexing.py", line 913, in search
> > thr002:     parsed_query = query_parser.parseQ(query)
> > thr002:   File "/local/share/UpLib-1.7.11/code/uplib/indexing.py", line 550, in parseQ
> > thr002:     query = QueryParser.parse(self, querystring)
> > thr002: JavaError: org.apache.jcc.PythonException: getFieldQuery_quoted
> > thr002: AttributeError: getFieldQuery_quoted
> >
> > thr002:     Java stacktrace:
> > thr002: org.apache.jcc.PythonException: getFieldQuery_quoted
> > thr002: AttributeError: getFieldQuery_quoted
> >
> > thr002: at org.apache.pylucene.queryParser.PythonMultiFieldQueryParser.getFieldQuery_quoted(Native Method)
> > thr002: at org.apache.pylucene.queryParser.PythonMultiFieldQueryParser.getFieldQuery(Unknown Source)
> > thr002: at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1421)
> > thr002: at org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1309)
> > thr002: at org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1237)
> > thr002: at org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1226)
> > thr002: at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206)
> >
> >
> > Bill
> >

repl: bad addresses:
[EMAIL PROTECTED] Andi Vajda <[EMAIL PROTECTED]> -- junk after local@domain (Andi)