How exactly do queries work? Are there universal methods?

[Akshay Ravikumar]

Hi,

I'm interning for a company right now, and I'm supposed to be helping them to migrate an existing C-based application from MySQL to Cassandra. I'm rather new to Cassandra, but I've been reading up on it for the past week and I have a good idea of how it works. However, I'm unsure as to how much I need to modify the existing code to work with Cassandra.

It seems that in the examples, a separate method needs to be written for each table's INSERT and SELECT statement, while things like CREATE and DROP can be done with the "execute_query" method I see defined in the examples.

Is this true? Do I need to write separate methods for every table I have, or is there some way to address INSERT/SELECT/etc for all of them?

Sorry, I'm very new to all this.

Akshay

[Michael Penick]

Hi Akshay,

That's probably because the INSERT and SELECT queries have specific bind parameters and/or custom result set handling. As opposed to the CREATE and DROP queries which only have a simple query string input and a success/fail result. 

Because different tables potentially have different inputs/outputs requirements you may need to handle queries for different tables with different calls into the API and depending on your design you might create separate functions to handle those queries. You could also use string manipulation to inline the values into the query string itself to unify all query logic to a single function, but that's general not recommended because of security issues and it also prevents your application from taking advantage of prepared statements. 

Currently, there isn't a single, generic function that handles different input types in the API, yet. I have thought about creating an interface in the driver that uses variadic arguments. That would simplify basic queries to a single API call. Here's what I was thinking.

Declaration:

CassFuture cass_session_execute_args(CassSession* session, const char* query, const char* types, ...);

"types" is a string where each character represents the type of a variadic argument at the corresponding position.

Type Mapping:

'i' is int32

'l' is int64

's' is CassString

'b' is CassBytes

'u' is CassUuid

...

Example Usage:

CassUuid uuid;

CassFuture* future 

  = cass_session_execute_args(session, "SELECT * from table1 WHERE column1 = ? AND column2 = ?", "ui", uuid, 1234);

Variadic arguments have problems though. If the "types" string doesn't match the actual type of the parameter it can cause memory corruption. There are ways to verify the parameters at compile time, but they are generally not portable. There's a story in JIRA to add such an interface: https://datastax-oss.atlassian.net/browse/CPP-105.

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to cpp-driver-us...@lists.datastax.com.

[mxmxmx]

Hi !
We just released an initial version of xcass (https://github.com/wattgo/xcass)
a bunch of helpers built on top of the C/C++ driver.

It already allows you to use variadic arguments while building query :

xcass_query_t *query =
xcass_query(xs, "SELECT * FROM playlists WHERE id = <uuid>", someCassUuid);

We found that using CQL syntax was less error prone compared to a more classical format string.

Have a look at examples for more info.

Still work to do (batch queries, prepared statement, ...) and under developpment but you can give a try !

feedback welcome :)
feel free to contribute !