[ 
https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091667#comment-13091667
 ] 

Mikko Koppanen commented on CASSANDRA-3025:
-------------------------------------------

Hi,

The problem is approx like this: PDO doesn't seem to allow variable number of 
columns per row. This means that I need to have a fixed amount of columns for 
each row. In the current approach I iterated the result set, found the row with 
most columns and used that as a column count for all rows. This causes a 
problem when some rows have less columns because those missing columns don't 
have names. 

In PHP arrays keys are either strings or ints, so the closest to setting the 
column name to null would be to pass in empty string. This however looks 
slightly confusing when columns are fetched as zero indexed and associative:

{code}
  array(7) {
    ["my_key"]=>
    string(9) "test user"
    [0]=>
    string(9) "test user"
    ["firstrowdata"]=>
    string(16) "Flat 1, Street 1"
    [1]=>
    string(16) "Flat 1, Street 1"
    [""]=>
    NULL
    [2]=>
    NULL
    [3]=>
    NULL
  }
{code}

As you can see there is an empty key, followed by key 2 which is the index 
value and the additional 3. This happens because the array keys must be unique 
so the first missing column sets key "" => NULL and then the second missing 
column sets the same key overriding it. However there are index values for both 
columns because those are unique (0 ... N).

With the current approach the following row is created:

{code}
  array(8) {
    ["my_key"]=>
    string(9) "test user"
    [0]=>
    string(9) "test user"
    ["firstrowdata"]=>
    string(16) "Flat 1, Street 1"
    [1]=>
    string(16) "Flat 1, Street 1"
    ["__column_not_set_2"]=>
    NULL
    [2]=>
    NULL
    ["__column_not_set_3"]=>
    NULL
    [3]=>
    NULL
  }
{code}

Which I thought is least confusing. I will investigate a bit more whether it 
would be possible to hack variable amount of columns in rows, but it didn't 
seem possible via the API.


As for the unparsing into objects: as explained before the array keys can be 
either strings or integers. Parsing into object would be problematic if the 
UUID is used as a column name, such as:

{code}
UPDATE uuid_test SET :uuid = 10 WHERE my_key = 'uuidtest'
{code}




> PHP/PDO driver for Cassandra CQL
> --------------------------------
>
>                 Key: CASSANDRA-3025
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3025
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API
>            Reporter: Mikko Koppanen
>              Labels: php
>         Attachments: pdo_cassandra-0.1.0.tgz, pdo_cassandra-0.1.1.tgz, 
> pdo_cassandra-0.1.2.tgz, php_test_results_20110818_2317.txt
>
>
> Hello,
> attached is the initial version of the PDO driver for Cassandra CQL language. 
> This is a native PHP extension written in what I would call a combination of 
> C and C++, due to PHP being C. The thrift API used is the C++.
> The API looks roughly following:
> {code}
> <?php
> $db = new PDO('cassandra:host=127.0.0.1;port=9160');
> $db->exec ("CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and 
> strategy_options:replication_factor=1;");
> $db->exec ("USE mytest");
> $db->exec ("CREATE COLUMNFAMILY users (
>                       my_key varchar PRIMARY KEY,
>                       full_name varchar );");
>                       
> $stmt = $db->prepare ("INSERT INTO users (my_key, full_name) VALUES (:key, 
> :full_name);");
> $stmt->execute (array (':key' => 'mikko', ':full_name' => 'Mikko K' ));
> {code}
> Currently prepared statements are emulated on the client side but I 
> understand that there is a plan to add prepared statements to Cassandra CQL 
> API as well. I will add this feature in to the extension as soon as they are 
> implemented.
> Additional documentation can be found in github 
> https://github.com/mkoppanen/php-pdo_cassandra, in the form of rendered 
> MarkDown file. Tests are currently not included in the package file and they 
> can be found in the github for now as well.
> I have created documentation in docbook format as well, but have not yet 
> rendered it.
> Comments and feedback are welcome.
> Thanks,
> Mikko

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to