https://issues.apache.org/jira/browse/HBASE-4887 has been created.
On Mon, Nov 28, 2011 at 3:42 PM, Doug Meil <[email protected]>wrote: > > I'd vote for the full enum name in the file too instead of the ordinal. > > > > On 11/28/11 5:58 PM, "Todd Lipcon" <[email protected]> wrote: > > >Seems like we're doing some over-optimization here using ordinals. Why > >not just write out the full enum name into the file? A few extra bytes > >in the header of a multi-MB HFile hardly seems expensive. > > > >Could probably switch this over in a backward-compatible manner pretty > >easily if someone has time to do the patch. > > > >-Todd > > > >On Mon, Nov 28, 2011 at 9:57 AM, Stack <[email protected]> wrote: > >> On Mon, Nov 28, 2011 at 8:26 AM, Doug Meil > >> <[email protected]> wrote: > >>> Hi folks- > >>> > >>> In Compression.java there is this commentŠ > >>> > >>> > >>> /** > >>> > >>> * Compression algorithms. The ordinal of these cannot change or else > >>>you > >>> > >>> * risk breaking all existing HFiles out there. Even the ones that > >>>are > >>> > >>> * not compressed! (They use the NONE algorithm) > >>> > >>> */ > >>> > >>> public static enum Algorithm { > >>> > >>> Š which makes the prospect of adding new instances slightly > >>>terrifying. Has anybody considered changing the constructor to supply > >>>an ordinal value, and that way if anybody adds a custom one they could > >>>supply a value like 9999999 or something hopefully never used by HBase? > >>> > >>> > >> > >> The comment is just to warn against damage if ordinals are removed or > >> reordered. Do whatever it is you need to make it work Doug. It > >> should be possible to insert other compressors w/o gymnastics. > >> St.Ack > >> > > > > > > > >-- > >Todd Lipcon > >Software Engineer, Cloudera > > > > >
