[
https://issues.apache.org/jira/browse/CASSANDRA-11004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105059#comment-15105059
]
Sylvain Lebresne commented on CASSANDRA-11004:
----------------------------------------------
To clarify, I'm talking of result-set metadata in general, not just LWT. But
you'll get {{\[json\]}} when you query JSON ({{INSERT INTO foo (...) JSON ?}})
and you'll get {{\[timestamp\]}} and {{\[ttl\]]}} when you do for instance
{{UPDATE foo USING TIMESTAMP ? AND TTL ? ...}}.
And you're really looking for trouble, you can get name collisions when using
functions since you can declare a column name like {{"blobAsInt( x)"}} if you
so wish.
Anyway, I'll also remark that even in all those case, even though there is a
name collision, you can still access each value by position properly. In
particular, I'd argue that result of the description is a bug of cqlsh/the
python driver as the {{\[applied\]}} flag _is_ available in the result-set sent
by the server, it's cqlsh/the driver that tangle them.
Overall, I'm not sure it's worth bothering with complicating the protocol for
this. I'll add some quick note to the CQL documentation about the kind of
column names users should avoid and I think this'll be good enough.
We should however probably fix cqlsh so that the example in the description
display:
{noformat}
cassandra@cqlsh:test> INSERT INTO test (k, "[applied]") VALUES (2, 3) IF NOT
EXISTS ;
[applied] | k | [applied]
-----------+---+-----------
False | 2 | 3
{noformat}
as that's what the server sends and is more correct.
> LWT results '[applied]' column name collision
> ---------------------------------------------
>
> Key: CASSANDRA-11004
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11004
> Project: Cassandra
> Issue Type: Bug
> Reporter: Adam Holmberg
> Priority: Minor
> Fix For: 4.x
>
>
> LWT requests return a not-well-documented single row result with a boolean
> {{\[applied]}} column and optional column states.
> If the table happens to have a column named {{\[applied]}}, this causes a
> name collision. There is no error, but the {{\[applied]}} flag is not
> available.
> {code}
> cassandra@cqlsh:test> CREATE TABLE test (k int PRIMARY KEY , "[applied]" int);
> cassandra@cqlsh:test> INSERT INTO test (k, "[applied]") VALUES (2, 3) IF NOT
> EXISTS ;
> [applied]
> -----------
> True
> cassandra@cqlsh:test> INSERT INTO test (k, "[applied]") VALUES (2, 3) IF NOT
> EXISTS ;
> [applied] | k
> -----------+---
> 3 | 2
> {code}
> I doubt this comes up much (at all) in practice, but thought I'd mention it.
> One alternative approach might be to add a LWT result type
> ([flag|https://github.com/apache/cassandra/blob/cassandra-3.0/doc/native_protocol_v4.spec#L518-L522])
> that segregates the "applied" flag information optional row results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
