cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11004) LWT results '[applied]' column name collision
Date Mon, 18 Jan 2016 10:15:39 GMT

    [ 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)

Mime
View raw message