cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6033) CQL: allow names for bind variables
Date Wed, 18 Sep 2013 08:07:51 GMT


Sylvain Lebresne commented on CASSANDRA-6033:

Btw, let me add that the name we currently send in the metadata as result of a PREPARE is
already not always a proper CQL3 column name. For instance, if you prepare:
UPDATE foo USING TTL ? SET m[?] = ? WHERE k = 0
then the bind variables will be respectively named '[ttl]', 'key(m)' and 'value(m)'.

So existing drivers already cannot really assume that the name returned is a true CQL3 column
name. Just to say that I doubt we'll break any existing driver by making this change, if that
is the fear.

> CQL: allow names for bind variables
> -----------------------------------
>                 Key: CASSANDRA-6033
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
> Currently bind variables are "anonymous", they're just a question mark. What this means
is that the only reliable way to reference those variables after preparation is through position
their position in the query string, which is not excessively user friendly.
> Of course some driver may be tempted to add their own version of named variables, but
that forces said driver to parse the query string in the first place, which is something we've
tried to avoid so far. Besides, this is useful enough that making it part of CQL would make
this more consistent amongst driver rather than having everyone coming up with its own syntax.
> I'll add that because we are already sending column names in the metadata, I believe
we can support this without any change to the protocol. The idea would be to support queries
like this (happy to discuss the exact syntax):
> {noformat}
> SELECT * FROM test WHERE key = ?my_key AND time > ?t_low AND time <= ?t_high
> {noformat}
> From the Cassandra side, the only thing that this would change is that in the result
set returned to the client, the column names would be 'my_key', 't_low' and 't_high' respectively
rather than 'key', 'time' and 'time' as they are now.  And so in particular using an anymous
variable would be equivalent to using a name one with the name of the CQL column the variable
is bound to.
> Driver side, the driver would just have to keep a map of each name to their position
in the metadata to provide reliable setter by names.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message