Re: NOT Operator with Parenthesis

[Jigar Shah]

LUCENE-6249  and
LUCENE-6857  will be
back-ported to 4.10.5. You may not need to jump to 5.X version for this.

Thanks,
Jigar Shah.

On Wed, Oct 28, 2015 at 5:19 AM, patel mrugesh 
wrote:

> Thanks Jigar :)
>
> It's really helpful.
>
>
>
> On Wednesday, 28 October 2015 12:05 AM, Jigar Shah 
> wrote:
>
>
> Most probably LUCENE-6249
>  changes parser's
> behavior, for your case.
>
>
> 
>
>
> On Tue, Oct 27, 2015 at 5:33 AM, patel mrugesh 
> wrote:
>
> Thanks for your reply Erick,
> I have gone through the document provided by you.
> However what I have observed is that there is difference if we parse query
> with Lucene 4.10.3 and Lucene 5.2.0 onwards.
> For example :Query String: lottery AND (NOT ticket)Lucene 4.x parsed it
> as: +lottery +ticket
> Lucene 5.1.x parsed it as: +lottery +(-ticket)
> And I want result as 5.1.x produces. But as I am not planning to upgrade
> lucene now so looking for fix for lucene 4.10.x.
> Please could you help on this?
> Thanks,Mrugesh
>
>
>
>  On Monday, 26 October 2015 8:03 PM, Erick Erickson <
> erickerick...@gmail.com> wrote:
>
>
>  Solr does not do strict Boolean logic, although it comes close. See:
> https://lucidworks.com/blog/2011/12/28/why-not-and-or-and-not/
>
> Best,
> Erick
>
> On Sun, Oct 25, 2015 at 11:18 PM, patel mrugesh
>  wrote:
> >  Hi All,
> > We are using Lucene 4.10.3, one strange behavior we have observed when
> NOT operator is used with parenthesis around.
> > It looks like NOT operator is completely ignored and whatever boolean
> operator was before parenthesis is applied.
> > For example, document text: "lottery ticket", query: "lottery NOT
> ticket". As expected, this query will not produce a match for this
> document. However, if this query is slightly modified and converted to
> "lottery (NOT ticket)" or "lottery AND (NOT ticket)" then match is
> produced. It behaves as if query becomes "lottery AND ticket" instead,
> completely ignoring NOT.
> > Please somebody can shed light on this?
> > Thanks,Mrugesh
> >
> >
> >
>
>
>
>
>
>
>

Re: NOT Operator with Parenthesis

[patel mrugesh]

Thanks Jigar :)
It's really helpful.
 


 On Wednesday, 28 October 2015 12:05 AM, Jigar Shah  
wrote:
   

 Most probably LUCENE-6249 changes parser's behavior, for your case.







On Tue, Oct 27, 2015 at 5:33 AM, patel mrugesh  
wrote:

Thanks for your reply Erick,
I have gone through the document provided by you.
However what I have observed is that there is difference if we parse query with 
Lucene 4.10.3 and Lucene 5.2.0 onwards.
For example :Query String: lottery AND (NOT ticket)Lucene 4.x parsed it as: 
+lottery +ticket
Lucene 5.1.x parsed it as: +lottery +(-ticket)
And I want result as 5.1.x produces. But as I am not planning to upgrade lucene 
now so looking for fix for lucene 4.10.x.
Please could you help on this?
Thanks,Mrugesh



     On Monday, 26 October 2015 8:03 PM, Erick Erickson 
 wrote:


 Solr does not do strict Boolean logic, although it comes close. See:
https://lucidworks.com/blog/2011/12/28/why-not-and-or-and-not/

Best,
Erick

On Sun, Oct 25, 2015 at 11:18 PM, patel mrugesh
 wrote:
>  Hi All,
> We are using Lucene 4.10.3, one strange behavior we have observed when NOT 
> operator is used with parenthesis around.
> It looks like NOT operator is completely ignored and whatever boolean 
> operator was before parenthesis is applied.
> For example, document text: "lottery ticket", query: "lottery NOT ticket". As 
> expected, this query will not produce a match for this document. However, if 
> this query is slightly modified and converted to "lottery (NOT ticket)" or 
> "lottery AND (NOT ticket)" then match is produced. It behaves as if query 
> becomes "lottery AND ticket" instead, completely ignoring NOT.
> Please somebody can shed light on this?
> Thanks,Mrugesh
>
>
>

  



  

Re: Two different types of values in same field name in single index

[Kumaran Ramasubramanian]

Hi Erick

Thanks a lot for the clarification.


​Regards,​
​K​
umaran
​R​


On Wed, Oct 28, 2015 at 1:47 AM, Erick Erickson 
wrote:

> I would be pretty skeptical of this approach You're
> mixing numeric data with textual data and I expect
> the results to be unpredictable. You already said
> "it is working for most of the
> documents except one or two documents." I predict
> you'll find more and more of these as time passes.
>
> Expect many more anomalies. At best you need to
> index both forms as text rather than mixing numeric
> and text data. Since you're not sorting you should be
> OK with the caveat that searching for
> "02" won't match an indexed value of "2" unless you
> remove all leading zeros at both index and query
> time.
>
> Best,
> Erick
>
> On Tue, Oct 27, 2015 at 11:31 AM, Kumaran Ramasubramanian
>  wrote:
> > Yes Will, You are right. But i dont use "status" field for sorting. i
> have
> > other fields that is being used for sorting specifically. And so i dont
> > face any issues in sorting as of now.
> >
> > --
> > Kumaran R
> >
> >
> > On Tue, Oct 27, 2015 at 7:20 PM, will  wrote:
> >
> >> Kumaran -
> >>
> >> Aren't you creating an unworkable scenario for sorting?
> >>
> >> -will
> >>
> >> On 10/27/15 5:49 AM, Kumaran Ramasubramanian wrote:
> >>
> >>> Hi All,
> >>>
> >>>   i have indexed module wise data in same index. In this case, we index
> >>> two
> >>> types of field in same name in two different document like this.
> >>>
> >>> *document1:*
> >>>
> >>> module:1
>  status:4 ( as LongField )
> 
>  *code:*
> >>>
> >>> long longValue=Long.parseLong(value);
>  LongField field=new LongField(f
>  ield
>  Name,longValue, Field.Store.YES);
>  document.add(field);
> 
> 
> >>> *document2:*
> >>>
> >>> module:2
>  status:open ( as Field )
> 
> >>> *code:*
> >>>
> >>>
>  Field field = new Field(
>  f
> 
>  ield
>  Name, value, (Field.Store) stored, (Field.Index) indexType);
> 
> >>> document.add(field);
> >>>
> >>>
> >>>
> 
>  There are around 50lakh documents in my index which has these kind of
> >>> mixed
> >>> type of fields
> >>>
> >>> when i query like status:4 or status:open, it is working for most of
> the
> >>> documents except one or two documents.
> >>>
> >>> Not able to reproduce the same in other indexes. So i want confirm
> whether
> >>> it is supported to have both Field & LongField with same field name in
> >>> same
> >>> index. And also Please suggest me any articles discussing this kind of
> >>> problem.
> >>>
> >>> Thanks :-)
> >>>
> >>> Related links:
> >>> http://www.gossamer-threads.com/lists/lucene/java-user/109530
> >>>
> >>> --
> >>> **
> >>> Kumaran R
> >>>
> >>>
> >>
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>