Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 19 May 2014 14:33:38 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12714754.1400240717624.3160.1400510018689@arcas>
In-Reply-To: <JIRA.12714754.1400240717624@arcas>
References: <JIRA.12714754.1400240717624@arcas>
Subject: [jira] [Commented] (CASSANDRA-7248) Tuple type
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Aleksey Yeschenko commented on CASSANDRA-7248:
----------------------------------------------

I don't think it is. You can emulate 6710 w/ tuples, but it's not a direct clone.

> Tuple type
> ----------
>
>                 Key: CASSANDRA-7248
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7248
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>              Labels: cql3
>             Fix For: 2.1 rc1
>
>
> For CASSANDRA-6875 we need to be able to talk about tuples values and types (for prepared variables). Since we need it there, clients will need to support them anyway and so I think it would be a lot cleaner to start supporting those more generally. Besides, having tuples is a relatively simple and natural extension to what we have. I'll note in particular that tuple have a close relationship to user type in the sense that a tuple will be really just like an anonymous with no name for the fields and in particular a tuple value will be the same than a user type value.
> The syntax would simply look like that:
> {noformat}
> CREATE TABLE foo (
>     k int PRIMARY KEY,
>     v tuple<int, text, float>
> )
> INSERT INTO foo(k, v) VALUES(0, (3, 'bar', 2.1));
> {noformat}
> We can also add projections in selects if we want:
> {noformat}
> SELECT v[0], v[2] FROM foo WHERE k = 0;
> {noformat}
> but that can come later (after all, we still don't have projections for collections and it's not a big deal).


--
This message was sent by Atlassian JIRA
(v6.2#6252)