lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Taylor <ij...@fastmail.fm>
Subject Re: is this lucene 4.1.0 bug in PerFieldPostingsFormat
Date Fri, 06 Mar 2015 15:22:59 GMT
On 06/03/2015 15:07, Michael McCandless wrote:
> On Thu, Mar 5, 2015 at 4:27 PM, Paul Taylor <paul_t100@fastmail.fm> wrote:
>> On 05/03/2015 19:01, Michael McCandless wrote:
>>> On Thu, Mar 5, 2015 at 12:12 PM, Paul Taylor <paul_t100@fastmail.fm>
>>> wrote:
>>>> On 05/03/2015 15:53, Paul Taylor wrote:
>>>>> On 05/03/2015 14:43, Michael McCandless wrote:
>>>>>> It looks like field was null?
>>>>>>
>>>>>> Back in 4.1.0 we just assert field != null, but in newer releases
it's
>>>>>> a real check.
>>>>>>
>>>>>> Mike McCandless
>>>>> Hi, thankyou Il try and get the query logged for when it next happens
>>>> Okay here are two lucene queries that cause the issue
>>>>
>>>> artist:pandora /reyli barba recording:Solo el y yo/Alguien llena mi lugar
>>>>
>>>> artist:Jeremih recording:Rated R (The Masterpiece) (Bear//Face Bootleg
>>>> Edit)
>>>>
>>>>
>>>> So I think the problem is that the users are not aware of the regular
>>>> expression syntax, escaping or removing the slashes and it works
>>>>
>>>> (Interestingly just removing one of the slashes
>>>>
>>>> artist:pandora /reyli barba recording:Solo el y yo Alguien llena mi lugar
>>>>
>>>> gives me the ParseException instead of the NullPointerException
>>>> )
>>> Which query parser are you using?  Seems like a bug if that query
>>> parser can do this ...
>> ClassicQueryParser, but the point is that we provide a webservice that allow
>> users to use the full query syntax as it would be impossible to second guess
>> what the user may want to do so I dont there is a bug in the queryparser in
>> that that way.  We just receive a text string that we send to Lucene, I
>> would hope if the syntax was incorrect Lucene would just give a
>> ParseException
> Well I think that means there is a bug in the query parser?
>
> I.e. it should throw a ParseException, not pass a null field value
> down to Lucene, when this query text is passed to it.
>
> Or it should set the field to a non-null value (not sure why it
> doesn't use the default field name for the RegexpQuery).
Right, did you see my last post the query parser does trap the exception 
if you enable assertions. I thought this was what you were saying was 
fixed in a later version, but assume you actually mean search is fixed 
not parser

>>>> But how can I fix this at my end so that Lucene returns an ParseException
>>>> rather than NullPointerException ?
>>> We need to fix the query parser.
>>>
>>>> Do you know the earliest verion of Lucene after 4.1.0 to handle this ?
>>> Sorry I don't offhand ... though the fix is to throw
>>> IllegalArgumentException instead of NPE.
>> Why not ParseException ?
>>> Why not just upgrade to the latest bugfix (4.10.4)?
>>>
>> In the past Ive generally tried to use the latest version of Lucene, but
>> there are usually at least some changes required even updating minor
>> versions. So  expect 4.10.4 will give me more issues, and if its going to
>> throw IllegalArgumentException rather than ParseExeption not sure that
>> helpful.
> Can you open a Jira issue and put a test case up?
Okay, yes if this is new issue, just waiting for confirmation from you.
> You could also try switching to the new "SimpleQueryParser": it does
> not even produce RegexpQuery.  It's quite dangerous to let users make
> arbitrary regexps ...
>
Is SimpleQueryParser identical to ClassicQueryParser without regular 
expressions, or not ?

Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message