Re: Backwards index format compatibility of future versions?

On 4/23/07, karl wettin <[EMAIL PROTECTED]> wrote: 23 apr 2007 kl. 06.39 skrev Lucifer Hammer: I'm curious, why is migrating the index not OK when it is OK to upgrade the software? It doesn't really add up in my head. We keep our indexed archives on write-once media. If we're forced to move

Re: Backwards index format compatibility of future versions?

23 apr 2007 kl. 06.39 skrev Lucifer Hammer: Thanks for that pointer! That link lead me to this link: http://wiki.apache.org/lucene-java/BackwardsCompatibility - Which makes it sound like I can only expect backwards compatibility within the current major version. Sorry, I read your post

Re: Backwards index format compatibility of future versions?

Thanks for that pointer! That link lead me to this link: http://wiki.apache.org/lucene-java/BackwardsCompatibility - Which makes it sound like I can only expect backwards compatibility within the current major version. When/if Lucene hits V3.0, it doesn't sound like there's a commitment for it

Re: Backwards index format compatibility of future versions?

23 apr 2007 kl. 06.10 skrev Lucifer Hammer: Should/can we expect that all future versions of Lucene will be able to read older indexes? Yes. -- karl

Backwards index format compatibility of future versions?

Hi, Is there a goal for lucene to always be able to read indexes written by older versions of Lucene? For instance, I noticed that I could read 2.0 and 1.9 indexes with a 2.1 Lucene jar. (I also noticed that if I add a document to one of those older indexes, then they'll be rewritten in 2.1 for

Re: IndexReader method semantics

Chris Hostetter wrote: : I'm considering making a kind of IndexReader where each time terms() is : called it might return a different sequence even though the reader : hasn't been reopened. okay *this* got my attention ... what are you working on? Basically I'm thinking of writing a different

Re: IndexReader method semantics

: I'm considering making a kind of IndexReader where each time terms() is : called it might return a different sequence even though the reader : hasn't been reopened. okay *this* got my attention ... what are you working on? : Would that kind of thing conceivably cause problems anywhere else in

Re: Top Score Collector

As to point <2>, the only way I was able to deal with this was by using a TopDocs, which does have a max score. But in that case, I don't believe you can limit the number of hits examined. I've just got to ask... Why do you (jafarim) want to fiddle with the threshold? How is this going to benefi

Re: Top Score Collector

Be aware that score thresholds don't work well in general since scores aren't really comparable from one query to another. What is I normalize the scores in such a manner that they become between 0 and 1? --jaf

Re: Top Score Collector

On 4/22/07, jafarim <[EMAIL PROTECTED]> wrote: I am trying to implement some TopScoreHitCollector class; a kind of TopDocCollector which collects the documents the score of which is higher than a threshold. The threshold will be configurable in the constructor of the class. There is seemingly a d

Re: Top Score Collector

On 4/22/07, jafarim <[EMAIL PROTECTED]> wrote: > Be aware that > score thresholds don't work well in general since scores aren't really > comparable from one query to another. What is I normalize the scores in such a manner that they become between 0 and 1? Two issues with that: 1) You never

Top Score Collector

Hi list. I am trying to implement some TopScoreHitCollector class; a kind of TopDocCollector which collects the documents the score of which is higher than a threshold. The threshold will be configurable in the constructor of the class. There is seemingly a document starvation about TopDocCollecto