Cassandra CQL: How to select encoded value from column

1
votes

I have inserted string and integer values into dynamic columns in a Cassandra Column Family. When I query for the values in CQL they are displayed as hex encoded bits.

Can I somehow tell the query to decode the value into a string or integer?

I also would be happy to do this in the CLI if that's easier. There I see you can specify assume <column_family> validator as <type>;, but that applies to all columns and they have different types, so I have to run the assumption and query many times.

(Note that the columns are dynamic, so I haven't specified the validator when creating the column family).

1
cassandra
Have you specified default_validation_class in your columnfamily specification? – Tamil
@Tamil: No - I haven't set the default_validation_class, because all the values are not the same type, so the validation would be wrong for some columns. – Martin Dow
then cql won't be able to do a valid decoding i think. By default it is bytestype i think. I haven't experiment assume let me try it for you – Tamil
Do columns with the same name not always have the same type? – the paul
@thepaul Yes, but I don't always know the column name at the time I'm creating the column family, so I can't set the encoding then. I might, for example, dynamically create a column like anchor:cnnsi.com which has type String and maybe a column like page-views:cnnsi.com of type long. So when I query in the cli/cql I want to decode each one appropriately. – Martin Dow

1 Answers

0
votes

You can use ASSUME in cqlsh like in cassandra-cli (although it only applies to printing values, not sending them, but that ought to be ok for you). You can also use it on a per-column basis, like:

ASSUME <column_family> ('anchor:cnnsi.com') VALUES ARE text;

..although (a), I just tested it, and this functionality is broken in cassandra-1.1.1 and later. I posted a fix at CASSANDRA-4352. And (b), this probably isn't a very versatile or helpful solution for more than a few one-off uses. I'd strongly recommend using CQL 3 here, as CQL direct support for wide storage engine rows like this is deprecated. Your table here is certainly adaptable to an (easier to use) CQL 3 model, but I couldn't say exactly what it would be without knowing more about how you're using it.