Integer column value inserted as string for composite primary key

[ioncube]

With 1.0.a.5, given a CF with a two part primary key, an insert of an integer column value appears to add the value as a string as reported by a CQL3 select, whereas a CQL insert adds as an integer. If the primary key is on the first column only, an insert of an integer works as expected. Code to reproduce with example output follows, with apologies if this is a user error on my part:

select \* from test; k1 | k2 | val ------+----+------- aKey | 33 | 12345 - After running script: * cqlsh:KS> select \* from test; k1 | k2 | val --------+----+--------- aKey | 33 | 12345 theKey | 42 | '12345' Failed to decode value '12345' (for column 'val') as Int32Type: unpack requires a string argument of length 4 */ ini_set('display_errors', 'on'); include_once('/usr/local/src/phpcassa-1.0.a.5/lib/autoload.php'); use phpcassa\Connection\ConnectionPool; use phpcassa\ColumnFamily; use phpcassa\SystemManager; $sys = new SystemManager('127.0.0.1'); $pool = new ConnectionPool('KS', array('127.0.0.1')); $cf = new ColumnFamily($pool, 'test'); $cf->insert_format = ColumnFamily::ARRAY_FORMAT; $cf->return_format = ColumnFamily::ARRAY_FORMAT; $key = 'theKey'; $cols = array( array(array(42, 'val'), 12345) ); $cf->insert($key, $cols);

[thobbs]

cql3-style column families with composite primaries keys cannot yet be easily supported through normal thrift clients like phpcassa due to a change in the way column metadata is stored. There is a ticket open to potentially change this, but I wouldn't expect it to be supported for a while.

[ioncube]

On 05.07.2012 16:24, Tyler Hobbs wrote:

cql3-style column families with composite primaries keys cannot yet be easily supported through normal thrift clients like phpcassa due to a change in the way column metadata is stored. There is a ticket open to potentially change this, but I wouldn't expect it to be supported for a while.

Thanks for the update. If the issue is simply that phpcassa lacks information about column types, and it's not a problem that would require a change to the standard cassandra distribution to solve, then one approach would be to assume the types based on the type of the value stored; "you give me a string to write, that's what I'm going to store, you give me an int, I'll write an int". As PHP only has a long integer size, you'd need a way to indicate the desired word size, which could be done with appropriate value classes, such as an Int32 class, Int64 class etc.

Alternatively, allow the phpcassa client to specify a full or partial schema so that knowledge of the richer cassandra types can be given, and on a type discrepancy either perform coercion performed or raise an exception (behaviour user selectable).

Nick