lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: Question about CompressingCodec
Date Thu, 15 Nov 2012 11:24:13 GMT
There's no real benefit except for perhaps discovery. I hit this code while
pressing F4 in eclipse on FilterCodec. I'm not sure that I'd do the same
for StoredFieldsFormat, but perhaps I just need to get used to it. It's
like how I discover Analyzers, I search for Analyzer extensions, not

But it's not critical, just thought that as a Codec, it's pretty generic.

I'm fine if we rename it only when the back-compat cannot be maintained any


On Thu, Nov 15, 2012 at 1:17 PM, Adrien Grand <> wrote:

> Hi Shai,
> On Thu, Nov 15, 2012 at 11:39 AM, Shai Erera <> wrote:
>> what if we made it a non-test class, which takes any Codec to wrap (i.e.
>> not default to Lucene41Codec)?
> What would be the benefits of having this class vs. extending FilterCodec?
>> While at that, should CompressingStoredFieldsFormat be named
>> CompressingStoredFieldsFormat41 or something like that, preparing it for
>> future changes? Or ... or we can add the version to the name only when it's
>> actually changed ...
> Given that this class is @lucene.experimental, I think we could do the
> following when modifying the file format:
>  - if backward compatibility is easy to maintain, just bump the version
> number
>  - otherwise copy all the logic to Lucene41StoredFieldsFormat (instead of
> making Lucene41StoredFieldsFormat extend CompressingStoredFieldsFormat) and
> we can then change anything we want in CompressingStoredFieldsFormat
> without worrying about backward compatibility.
> --
> Adrien

View raw message