Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C12F010E79 for ; Mon, 1 Jul 2013 14:56:26 +0000 (UTC) Received: (qmail 53158 invoked by uid 500); 1 Jul 2013 14:56:26 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 52169 invoked by uid 500); 1 Jul 2013 14:56:22 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 51865 invoked by uid 99); 1 Jul 2013 14:56:20 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Jul 2013 14:56:20 +0000 Date: Mon, 1 Jul 2013 14:56:20 +0000 (UTC) From: "Sylvain Lebresne (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-5715) CAS on 'primary key only' table MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696860#comment-13696860 ] Sylvain Lebresne commented on CASSANDRA-5715: --------------------------------------------- I understand that, but CQL doesn't ever allow a PK column to be in the SET clause contrarily to SQL. So allowing it in just that case wouldn't make sense unless we start allowing PK columns in the SET clause in general. Note sure it's worth going there. > CAS on 'primary key only' table > ------------------------------- > > Key: CASSANDRA-5715 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5715 > Project: Cassandra > Issue Type: Improvement > Reporter: Sylvain Lebresne > Priority: Minor > > Given a table with only a primary key, like > {noformat} > CREATE TABLE test (k int PRIMARY KEY) > {noformat} > there is currently no way to CAS a row in that table into existing because: > # INSERT doesn't currently support IF > # UPDATE has no way to update such table > So we should probably allow IF conditions on INSERT statements. > In addition (or alternatively), we could work on allowing UPDATE to update such table. One motivation for that could be to make UPDATE always be more general to INSERT. That is currently, there is a bunch of operation that INSERT cannot do (counter increments, collection appends), but that "primary key table" case is, afaik, the only case where you *need* to use INSERT. However, because CQL forces segregation of PK value to the WHERE clause and not to the SET one, the only syntax that I can see work would be: > {noformat} > UPDATE WHERE k=0; > {noformat} > which maybe is too ugly to allow? > -- 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