On Tue, Feb 9, 2010 at 9:08 AM, Renaud Delbru <renaud.del...@deri.org> wrote: > Hi Michael, > > On 09/02/10 13:35, Michael McCandless wrote: >> >> It's great that you're testing the flex APIs... things are still "in >> flux" as you've seen. There's another big patch pending on >> LUCENE-2111... >> > > So, does it mean that the codec interface is likely to change ? Do I need to > be prepared to change again all my code ;o) ?
This particular patch doesn't change the Codecs API -- it "only" factors out the Multi* APIs from MultiReader. Likely you won't need to change your codec... but try applying the patch and see :) However: if you consume the flex API directly, on top of multi readers (something you shouldn't do, for performance reasons), you will have to use MultiField's static methods to get the enums. >> Out of curiosity... in what circumstances do you see a Multi*Enum >> appearing? >> >> Lucene's core always searches "by segment". Are you doing something >> external (directly using the flex APIs against a >> Multi/DirectoryReader)? > > I am using the flex API with the high level Lucene interface (IndexWriter > and IndexReader). > I am creating a RamDirectory, register my codec into the IndexWriter, and > index 64 documents. Then, I use the IndexReader.termPositionsEnum to get my > own DocsAndPositionsEnum in order to check if all the information that have > been stored in the new index data structure are correctly retrieved. > In that case, I got the previous errors (a MultiDocsAndPositionsEnum is > returned). However, when I am indexing only one or two documents, the > original DocsAndPositionsEnum is returned. Got it, so you're directly consuming the flex API in your test. Whenever the index has > 1 segment, you'll get a multi enum. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
