Implement setting the keyspace on statement

[muzarski]

API:

• cass_statement_set_keyspace
• cass_statement_set_keyspace_n
• cass_batch_set_keyspace
• cass_batch_set_keyspace_n

[wprzytula]

Doesn't this feature require CQLv5?

[muzarski]

Doesn't this feature require CQLv5?

To actually do something, yes. For CQLv4 it's basically a no-op.

[wprzytula]

Doesn't this feature require CQLv5?

To actually do something, yes. For CQLv4 it's basically a no-op.

In such case, is it worthy implementing this function at all?

[muzarski]

In such case, is it worthy implementing this function at all?

I don't think so. But before closing the issue, I'd firstly update Limitations sections in readme.

I'll also summarize what this method does for CQLv4:
The documentation says that it can be used for token-aware routing (this may only be useful for unprepared statements). Ok, but for vnodes, we are also missing the token - there is an API that allows us to obtain the token from unprepared statement, namely:

/**
 * Adds a key index specifier to this a statement.
 * When using token-aware routing, this can be used to tell the driver which
 * parameters within a non-prepared, parameterized statement are part of
 * the partition key.
 *
 * Use consecutive calls for composite partition keys.
 *
 * This is not necessary for prepared statements, as the key
 * parameters are determined in the metadata processed in the prepare phase.
 *
 * @public @memberof CassStatement
 *
 * @param[in] statement
 * @param[in] index
 * @return CASS_OK if successful, otherwise an error occurred.
 */
CASS_EXPORT CassError
cass_statement_add_key_index(CassStatement* statement,
                             size_t index);

This is all we need to properly route the request for v-nodes only, correct? Or am I missing something?

This is still a bit useless for the tablets - we need the table information. Well, the driver could technically parse the table name from the CQL statement, but this is too much hussle - let's drop this idea. So we could define an API like cass_statement_set_table. The set of these 3 methods would allow us to properly route the unprepared statements, correct?

So, what are the benefits of creating unprepared statement, setting the key indexes, keyspace and table? I don't see any - just prepare the statement... You won't event save a round trip this way, because rust-driver prepares the statement anyway for the type-safety during serialization.

So, to summarize - I believe this API is redundant.