[ https://issues.apache.org/jira/browse/CASSANDRA-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14004015#comment-14004015 ]
Tyler Hobbs commented on CASSANDRA-7248: ---------------------------------------- Overall the patch looks pretty good. I'd like to see some thorough integration tests (similar to user_types.py in the dtests) and maybe some unit tests on TupleType.compare() and TupleType.validate(). I'll start extracting/backporting this for 6875. > 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)