[
https://issues.apache.org/jira/browse/CASSANDRA-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770550#comment-13770550
]
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:
{noformat}
UPDATE foo USING TTL ? SET m[?] = ? WHERE k = 0
{noformat}
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: https://issues.apache.org/jira/browse/CASSANDRA-6033
> 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: http://www.atlassian.com/software/jira
