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