lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3126) IndexWriter.addIndexes can make any incoming segment into CFS if it isn't already
Date Tue, 24 May 2011 13:47:47 GMT


Shai Erera commented on LUCENE-3126:

bq. Right, these too only live outside a CFS. You create them by opening a writable IndexReader
(I know: confusing!) and calling setNorm, then closing it. They are not only for old indices...
4.0 creates them too.

Thanks Mike ! I was able to reproduce it and fix it (+ add to test). Are there other files
that are normally created outside the .cfs? I've seen sometimes that the stored fields of
CFS are created outside. Was it only for shared doc stores?

bq. More generally: does addIndexes properly refuse to import a too-old index? We should throw
IndexFormatTooOldExc in this case? (And, maybe also IndexFormatTooNewExc?).

Not today. I believe it will fail in later stages (e.g. commit()), but we better fail up front.
I think it's a separate issue though, only for 4.0 (b/c 3x supports all formats today)?

> IndexWriter.addIndexes can make any incoming segment into CFS if it isn't already
> ---------------------------------------------------------------------------------
>                 Key: LUCENE-3126
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>            Priority: Minor
>             Fix For: 3.2, 4.0
>         Attachments: LUCENE-3126.patch
> Today, IW.addIndexes(Directory) does not modify the CFS-mode of the incoming segments.
However, if IndexWriter's MP wants to create CFS (in general), there's no reason why not turn
the incoming non-CFS segments into CFS. We anyway copy them, and if MP is not against CFS,
we should create a CFS out of them.
> Will need to use CFW, not sure it's ready for that w/ current API (I'll need to check),
but luckily we're allowed to change it (@lucene.internal).
> This should be done, IMO, even if the incoming segment is large (i.e., passes MP.noCFSRatio)
b/c like I wrote above, we anyway copy it. However, if you think otherwise, speak up :).
> I'll take a look at this in the next few days.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message