[
https://issues.apache.org/jira/browse/CASSANDRA-7248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14001502#comment-14001502
]
Sylvain Lebresne commented on CASSANDRA-7248:
---------------------------------------------
bq. I'm a little hesitant to expose a new type just because we can.
It's not because we can. It's because we *have to* expose it if we do
CASSANDRA-6875. That is, if we do CASSANDRA-6875, we will have TupleType, it
will be part of the native protocol and it will be a type visible to users
since they that will be a type of bind variables. To take the Java driver as
example, this imply that we will need to have a 'tuple type' in
[DataType|https://github.com/datastax/java-driver/blob/2.0/driver-core/src/main/java/com/datastax/driver/core/DataType.java]
and will need to introduce a new "tuple" class for tuple values so user can
pass them for CASSANDRA-6875. All of this even if we don't expose tuple as
column types and all of this is user facing. So adding TupleType for
CASSANDRA-6875 without adding it as a column type would 1) don't really save
any effort neither C* side nor driver side and 2) ends up with a type that does
exist and user can see, but can't use themselves, which imo is a *lot* more
confusing/frustrating for users.
As for use cases, they are basically the same than UDT, except that when you
have only 2-3 fields to group together (in a collection for instance), it might
sometimes be cleaner/simpler/preferred to have a tuple than to declare a new
UDT. This is definitively just a convenience, but that's what UDT are too in
the first place, a convenience, and that's what CQL is about too. Also since we
use the same serialization format, we can also allow user to switch from tuple
to UDT, so they may want to start with a tuple initially during the prototyping
phase and later move to a true UDT when they end up adding more fields. And
since tuples are a pretty familiar concept, I doubt having that choice will
throw users off.
Don't get me wrong, we can decide to not do CASSANDRA-6875, in which case I
won't insist on this (even though I do think it's nice to have in any case).
But having tuples only half supported is imo the worst choice of all.
> 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)
