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

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 m

Re: NOT Operator with Parenthesis

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 p

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

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

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

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:* modu

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

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 > Na

Re: NOT Operator with Parenthesis

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 Lucen

Access query length inside similarity

Hi, How can I access length of the query (number of words in the query) inside a SimilarityBase implementation? P.S. I am implementing multi-aspect TF [1] for an experimental study. So it does not have to be fast/optimized as production code. [1] http://dl.acm.org/citation.cfm?doid=2484028.2484