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 >
