Ed Kohlwey 2013-07-05, 11:59
Josh Elser 2013-07-05, 12:39
Josh Elser 2013-07-05, 13:50
Ed Kohlwey 2013-07-05, 14:38
Keith Turner 2013-07-05, 17:13
Ed Kohlwey 2013-07-05, 14:33
Keith Turner 2013-07-05, 16:40
Josh Elser 2013-07-05, 17:07
Ed Kohlwey 2013-07-05, 17:31
Ed Kohlwey 2013-07-05, 17:27
On Fri, Jul 5, 2013 at 1:27 PM, Ed Kohlwey <[EMAIL PROTECTED]> wrote:
>> It would be very nice if the types you mentioned were more consistent
>> across the API. Personally I would like to see byte and ByteSequence
>> fully supported across all of the APIs related to reading and writing data.
>> We added support for byte to mutation in 1.5. Thinking back, we should
>> have added support for ByteSequence too.
> +1. If we make everything tie back to ByteSequence and make the
> serialization/deserialization logic pluggable, then everyone will be happy.
> Do you have any ideas based on the sketch I included that would help make
> this better for all types, not just byte?
I'd be very cautious about making *everything* tie back to
ByteSequence. Some things, are more constrained than bytes... such as
Column Visibilities, which we assume are human-readable strings, and
it'd be more appropriate to tie it back to CharSequence than
ByteSequence in the API, even though internally it's just bytes. The
bytes we store for this should really be UTF8-encoded characters.
Table names are another place where we use Text sometimes in the API
to refer to something containing a String/CharSequence and cannot be
arbitrary bytes... though I don't think your proposal affects that
part of the API as much.
Christopher L Tubbs II
Ed Kohlwey 2013-07-08, 14:22
Christopher 2013-07-08, 16:28
devramiyer1@... 2013-07-06, 04:11