lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Created] (LUCENE-5126) Codec classes/packages that do not provide (automatic) file format back should throw an explicit exception
Date Fri, 19 Jul 2013 17:58:48 GMT
Hoss Man created LUCENE-5126:

             Summary: Codec classes/packages that do not provide (automatic) file format back
should throw an explicit exception
                 Key: LUCENE-5126
             Project: Lucene - Core
          Issue Type: Improvement
            Reporter: Hoss Man

If a user builds an index with an alternate codec that does not provide (automatic) backcompat
for reads in future versions of lucene, the resulting error if the user tries to upgrade can
be obscure and missleading -- suggesting either index corruption or a code bug w/o any obvious
indicator that the real problem is that the user needs to explicitly convert the index format.
 (Even if we document the hell out of this -- LUCENE-5125 -- so users have to know about it
when they pick a codec, the person who picked the codec for an app may be long gone when some
other poor sap tries to upgrade that app to use a newer version of Lucene)

For example, as demonstrated in  LUCENE-5121 if a user uses "Disk" based doc values in 4.2.1,
and then tries upgrading to 4.4, they might get...

{noformat} read past EOF: MMapIndexInput(path="/home/hossman/tmp/disk_docvals_bug/collection1/data/index/_0_Disk_0.dvdm")

or they might get...

org.apache.lucene.index.CorruptIndexException: invalid type: 65, resource=MMapIndexInput(path="/storage/solrdata/index/_fd_Disk_0.dvdm")
{noformat} would be a lot better for our users if in situations like this we could give them a
clear and definitive indication (similar to "IndexFormatTooOldException") that the codec they
are using has changed in a non-backcompat way, and that they need to explicitly convert their
index to supported codec before upgrading.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

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

View raw message