BooleanQuery rewrite optimization

Hello all, I noticed while debugging a query that BooleanQuery will rewrite itself to remove FILTER clauses that are also MUST as an optimization/simplification, which makes total sense. So (+f:x #f:x) will become (+f:x). However, shouldn't there also be another optimization to remove FILTER

Re: BooleanQuery rewrite optimization

Off the top of my head, i think any optimiation like that would also need to account for minNrShouldMatch, wouldn't it? if your query is "(X Y Z #X)" w/minshouldmatch=2, and you rewrite that query to "(+X Y Z)" w/minshouldmatch=2 you now have a semantically diff query that won't match as many

Re: BooleanQuery rewrite optimization

Hm, I hadn't really thought about the minShouldMatch part, I thought it' d be covered but I see your point being semantically different if you keep it as is. However.. Running your edge case example on an actual local index I get the following: "(X X Y #X)" w/minshouldmatch=2 vs. (+X X Y)

Newbie Questions

I am new to Lucene and couple of questions. I have worked with SOLR previously, now trying to work directly with Lucene to get similar functionality(but without SOLR). Below are my questions, thanks in advance. 1) In SOLR, there is functionality of copyfields, which dynamically copies one field

Re: Newbie Questions

Can anyone please reply ? . Regards. -- View this message in context: http://lucene.472066.n3.nabble.com/Newbie-Questions-tp4290817p4290854.html Sent from the Lucene - Java Users mailing list archive at Nabble.com. - To

RE: Any compatiblity issue in the upgrade from Lucene Core 3.2.0 to Core 6.1.0?

Thanks to Erick. So you mean that we can use the IndexUpgrader to:  Upgrade the index from 3.x to 4.x  And then upgrade from 4.x to 5.x  Finally we upgrade the index from 5.x to 6.x Do we need to upgrade the application for each stage? Or we just need to build our

Re: Any compatiblity issue in the upgrade from Lucene Core 3.2.0 to Core 6.1.0?

On Mon, Aug 8, 2016 at 1:37 PM, Erick Erickson wrote: > Yes. Lucene only guarantees back-compatibility with > indexes for one major version. That is, a 4.x release can > read a 3.x Lucene index. But a 5.x will not read a 3.x. > > So you have some options here: > 1>

Re: Any compatiblity issue in the upgrade from Lucene Core 3.2.0 to Core 6.1.0?

On Tue, Aug 9, 2016 at 12:36 PM, 郑文兴 wrote: > Then it sounds like that "re-index all the sources in 6.x" is the most > feasible way, :(. If you can, that's what I would do. There are newer features you'll want to use anyway and migrating in doc values and the like is not the

RE: Any compatiblity issue in the upgrade from Lucene Core 3.2.0 to Core 6.1.0?

Then it sounds like that "re-index all the sources in 6.x" is the most feasible way, :(. -Original Message- From: Trejkaz [mailto:trej...@trypticon.org] Sent: Tuesday, August 09, 2016 10:32 AM To: Lucene Users Mailing List Subject: Re: Any compatiblity issue in the upgrade from Lucene

Partial update to document

Hi There, Is there a way to partially update the document ? I know there's a API updateDocument on IndexWriter, but that seems to create a new document with just a field i am specifying. What i want is delete some fields from existing(indexed) document, and then add some new fields(could or not

Segment Corruption - ForUtil.readBlock AIOBE

For some of the segments we received the following exception during merge as well as search. They look to be corrupt [Lucene 4.6.1 & Sun JDK 1.7.0_55] Is this a known bug? Any help is much appreciated The offending line of code is in ForUtil.readBlock() method... *final int encodedSize =

Re: Segment Corruption - ForUtil.readBlock AIOBE

Can you run checkindex and include the output? On Mon, Aug 8, 2016 at 2:36 AM, Ravikumar Govindarajan wrote: > For some of the segments we received the following exception during merge > as well as search. They look to be corrupt [Lucene 4.6.1 & Sun JDK >