Gotcha, I probably should have guessed that much. Does CQL have any
functions to convert ascii to hex so that I don't have to do that
conversion elsewhere (I don't see one in the docs)?
On Thu, May 3, 2012 at 2:09 PM, paul cannon <p...@datastax.com> wrote:
> On Thu, May 3, 2012 at 12:46 PM, Eric Czech <e...@nextbigsound.com> wrote:
>
>> I can't believe I have to ask this but I have a CF with about 10 rows and
>> the keys are literally 1 through 9.
>>
>> Why does this not work if I want the row where the key is ascii('5')?
>>
>> cqlsh:Keyspace1> select first 1 * from CF where key = '5';
>> KEY
>> -----
>> 05
>>
>
> This depends on the configured type (key_validation) of the key. From what
> you've posted, it looks like CQL is treating it as 'blob', not 'ascii'.
>
> * I saw the Jira about the sort of phantom row with no values so I know
>> why that's there
>>
>> Listing the keys shows something like this:
>>
>> cqlsh:Keyspace1> select key from CF ;
>> key
>> ------
>> 33
>> 36
>> 35
>> 38
>> 32
>> 31
>> 39
>> 34
>> 37
>>
>> If I prepend a '3' to my key queries it works but I can't possibly see
>> why I would have to do that.
>>
>> cqlsh:Keyspace1> select first 1 * from CF where key = '35';
>> ( Returns the right rows for key '5')
>>
>
> Cause 35 is hex for ascii(5), as you pointed out.
>
> Changing the validator appears to make no material difference beyond the
>> key listing:
>>
>
> This is because ASSUME is only a cqlsh feature, and only affects how data
> is deserialized. There is a ticket out for cqlsh also to mangle your
> outgoing CQL statements to match ASSUMEd types too, but that's not there
> yet.
>
> HTH,
> p
>
