[
https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089700#comment-13089700
]
Jonathan Ellis edited comment on CASSANDRA-3025 at 8/23/11 7:48 PM:
--------------------------------------------------------------------
bq. Improved column metadata:
That's good to have (is there no place for "table" level metadata though?) but
by "one demonstrating introspection of default_validation_class" I mean, I'd
like to see it turning int data into int results, for instance. But if you're
planning to get to that later, that's fine.
bq. added test for bigints
- Suggest not calling the CF "standardlong" when it's really containing bigints
- should test an actual "big" int (> 64bit)
bq. is there an easier way to get column metadata
No. The approach Java and Python take is to get the metadata once when the
connection is opened and cache it. This isn't entirely without its own
problems (CASSANDRA-2734) but works reasonably well.
See also CASSANDRA-2477.
bq. Is there a way to query the currently "in use" keyspace? Currently I added
following but it doesn't seem very clean
That's pretty much what Java and Python do, too.
was (Author: jbellis):
bq. Improved column metadata:
That's good to have (is there no place for "table" level metadata though?) but
by "one demonstrating introspection of default_validation_class" I mean, I'd
like to see it turning int data into int results, for instance. But if you're
planning to get to that later, that's fine.
bq. added test for bigints
- Suggest not calling the CF "standardlong" when it's really containing bigints
- should test an actual "big" int (> 64bit)
bq. is there an easier way to get column metadata
No. The approach Java and Python take is to get the metadata once when the
connection is opened and cache it. This isn't entirely without its own
problems (CASSANDRA-2734) but works reasonably well.
See also CASSANDRA-3002.
bq. Is there a way to query the currently "in use" keyspace? Currently I added
following but it doesn't seem very clean
That's pretty much what Java and Python do, too.
> 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,
> 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
