It was I who did it that way. -1 on reintroducing Text.
No need to store the values as strings. We can store ints as varint representation in byte[], etc. I used strings only so printing the map from the shell gives reasonable human readable representation, with the expectation that the values will be rarely consulted beyond startup and region deployment times. If this consideration has become inconvenient for other uses and those uses outweigh the readability consideration, +1 to use Bytes and/or Writables to marshall and unmarshall other types avoiding transitions through string objects. - Andy > From: Erik Holstad <[email protected]> > Subject: Structure of values map in HColumnDescriptor. > To: [email protected] > Date: Monday, April 6, 2009, 6:12 PM > Today we have a values map in HColumnDescriptor that maps > strings of names to ints, booleans and strings. > For a int value you make a string out of it, then you do > getBytes on that string to get the bytes and finally new > ImmutableBytesWritable to store it in the map. > I'm not a big fan of the Text format and I'm happy > that we are trying to get rid of it in as many places as > possible but I think that this is one of the cases where > is would actually make sense to keep them, so we don't > have to create all these new objects just to write them > and have something like a map<Text, Text> or map<Text, > IntWritable>. > If choosing the last option we need to convert the one > place where strings are used for the values, > compressiontype, to an int. > > Regards Erik
