Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 19 Jun 2012 05:06:43 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <225300059.28455.1340082403425.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <984045656.26865.1324315771992.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-3647) Support set and map value types
 in CQL
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396516#comment-13396516 ] 

Jonathan Ellis commented on CASSANDRA-3647:
-------------------------------------------

The read-before-write operations on list concern me, since we've avoided these operations thus far (e.g., {{UPDATE foo SET x=y WHERE w=z}}).  I've been a fan of the status quo since forcing the client to do the read explicitly makes it clear that you're performing a race-prone sequence.  Yes, it's less efficient, but in most cases the cost of doing random reads dwarfs the round-trip overhead.

I'd also note that to my knowledge no other implementation of documents or containers allows efficient updates of individual items.  If we force the user to fetch the list, then overwrite the entire list with the desired items removed, we're no worse than the competition. :)

Am I off base?  Is it time to embrace the race and add this kind of server-side sugar?
                
> Support set and map value types in CQL
> --------------------------------------
>
>                 Key: CASSANDRA-3647
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>              Labels: cql
>             Fix For: 1.2
>
>
> Composite columns introduce the ability to have arbitrarily nested data in a Cassandra row.  We should expose this through CQL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira