cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3647) Support set and map value types in CQL
Date Tue, 12 Jun 2012 12:51:43 GMT


Sylvain Lebresne commented on CASSANDRA-3647:

bq. I'd argue that if you cared more about the value than the ordering, you should be using
a Set instead.

Ok, but what if you care a little bit of both. Or even if you started with a list because
you though that it was what you wanted but end up using it like a set and don't want to migrate
data. I mean, I'm playing devil's advocate here and I'm not pretending those are very common
case, but I do have a problem with limiting the supported features "because we can't come
up with a nice syntax for it". That being, I mentioned that "problem" because it came to mind
but we can always keep the "method syntax" for those methods for which we don't have a better

bq. what else would S[4] mean? That is: I'm okay with being non-standard, as long as it's
not ambiguous.

I'm not saying it's ambiguous, I'm saying there is maybe better. The square bracket notation
for lists and maps is use to select a value by key and you can use it to set the value for
that key too. This is not really what this would does for sets, as it would rather select
a provided value in the set. So I submit that maybe not reusing the square bracket notation
may end up being clearer. But this also boils down to the list discard thing. I disagree we
shouldn't have a discard for lists, and as it happens DELETE S['foo'] would be exactly the
equivalent of L.discard('foo') (where S is a set and L a list), so it feels wrong to reuse
the syntax that for list does discard_idx, not discard.
> Support set and map value types in CQL
> --------------------------------------
>                 Key: CASSANDRA-3647
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message