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

Sylvain Lebresne commented on CASSANDRA-7248:
---------------------------------------------

Ok, I've now pushed some tests on the same branch than above. But since we 
decided to use the unit tests suite for CQL tests, I've created a CQLTester 
class that is meant to be extended by CQL tests and that provide convenience 
methods for execute and asserts. One of the nice property of it being that all 
tests can be executed using either the prepared path or the normal, query 
string, path (without writing every test twice that is).

I've added a bunch of tuple tests using that. I've also migrated 
MultiColumnRelationTest (the only CQL test we have in the unit tests so far) to 
use that new CQLTester class.


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

Reply via email to