[
https://issues.apache.org/jira/browse/CASSANDRA-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770523#comment-13770523
]
Sylvain Lebresne commented on CASSANDRA-6033:
---------------------------------------------
I've seen at least a few users asked for something like this on the driver
side, so not totally sure everyone is fully happy with the status quo. I mean,
if I was convinced that everyone would say "well, that's not supported, fair
enough, I'll do without it, no biggy", then I'd agree with you. But my fear is
that people will be annoyed and start messing with query strings to try doing
the equivalent of this. I'm afraid of drivers doing it all in their own way and
being made more fragile by having to parse/search-and-replace the query string.
Do I wish we'd have done that sooner: sure. But typically my suggestion would
be to do that for the protocol v2 only, i.e. change the spec of the protocol to
say that the name in the result set is not the name of the CQL3 column, but
rather the name of the bind variables. Which by default would be the CQL3
column name. We can do that spec change now, in 2.0.1, so client drivers can
know what to expect. I strongly doubt anyone is in production with C* 2.0.0 and
the native protocol v2 (if only because it's buggy in 2.0.0: CASSANDRA-6040).
Then we can ship the syntax change in say 2.0.2: it's not a very complicated
change to make.
> 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
