Question about CompressingCodec

[Shai Erera <se...@gmail.com>]

Hi

I looked at CompressingCodec and had a couple of questions until I realized
it's a test code only. I understand that creating a Codec class is not
favorable, because of back-compat issues (that may arise in the future), so
I'll ask that -- what if we made it a non-test class, which takes any Codec
to wrap (i.e. not default to Lucene41Codec)? I don't have any strong
feelings for or against it, so I'm ok if the general feeling is that we
should provide CompressingStoredFieldsFormat only.

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 ...

Shai

Re: Question about CompressingCodec

[Shai Erera <se...@gmail.com>]

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
TokenStreams/Filter.

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
longer.

Shai

On Thu, Nov 15, 2012 at 1:17 PM, Adrien Grand <jp...@gmail.com> wrote:

> Hi Shai,
>
> On Thu, Nov 15, 2012 at 11:39 AM, Shai Erera <se...@gmail.com> 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
>

Re: Question about CompressingCodec

[Adrien Grand <jp...@gmail.com>]

Hi Shai,

On Thu, Nov 15, 2012 at 11:39 AM, Shai Erera <se...@gmail.com> 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