On Aug 18, 2010, at 10:13 PM, Andi Vajda wrote: > On Wed, 18 Aug 2010, Aric Coady wrote: >> #query = queryParser.parse(queryString) >> query = queryParser.parse(Version.LUCENE_CURRENT, queryString, fields, >> [BooleanClause.Occur.SHOULD, >> BooleanClause.Occur.SHOULD], >> analyzer) >> > Whenever there is a name conflict between a static and non-static method > detected by JCC, the static method wrapper is renamed to be suffixed with a > '_' and a warning is emitted by JCC. > > Does changing the code to use a parse_() method instead solve the problem ? > (it's late here and I haven't tried it myself)
Ah, so there are couple different things going on here. MultiFieldQueryParser has only static parse methods, except that it also inherits QueryParse.parse. Perhaps that's why JCC isn't supplying a parse_ method. >>> lucene.MultiFieldQueryParser.parse <built-in method parse of type object at 0x10171d800> >>> lucene.MultiFieldQueryParser.parse_ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: type object 'MultiFieldQueryParser' has no attribute 'parse_' >>> lucene.QueryParser.parse <method 'parse' of 'QueryParser' objects> This gotcha has come up before: http://mail-archives.apache.org/mod_mbox/lucene-pylucene-dev/201007.mbox/%3caanlktinkhxsiqp7jljz1q0cy6cv03y5umyzvg8a5d...@mail.gmail.com%3e. But as known limitations go, it's an easy workaround. Just call QueryParser.parse with the parser object as the first argument. As for the wildcard issue, I was trying to point out that I don't think it's a pylucene problem at all. The example given was calling the static MultiFieldQueryParser.parse with a parser object, incorrectly expecting settings on the parser object to have an affect. The fact that calling queryParser.parse(queryString) raises a TypeError is technically unrelated, although probably adding to the confusion.
