[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294999#comment-13294999
]
Sylvain Lebresne commented on CASSANDRA-3647:
---------------------------------------------
bq. Fair point, but I feel like a Set is more like a Map with no value, than a
List with no indexes
Ok, let me rephrase a bit my argumentation.
# The first point is that "S[4]" for sets is not a standard notation at all.
That doesn't mean we cannot use it (there is no standard notation for that kind
of operation that I know of anyway), but that does mean that another notation
would be equaly good. And not reusing a very standard notation for something
new could actually be a good point: I've learned that we don't all have the
same intuition when it comes to syntax, and I would halfway expect some people
to think that S[4] actually means "the 4th elements of the (sorted) set S".
# Then there is the fact that we don't have a syntax for List.discard and I do
think there is no good reason not to support it (not having a syntax is
definitely not a good reason as far as I'm concerned; I prefer supporting it
with a slightly ugly syntax than none at all). And the thing is, List.discard
is very much the same operation than Set.discard, or at least it's much closer
in semantic than List.discard_idx is of Set.discard. So inventing a syntax for
both List.discard and Set.discard would be coherent.
So the notation I'm suggesting is to use curly brackets instead of square ones,
so S{4}. The meaning of such would be to 'select the value 4 in the set S if
present'.
I will note that supporting such notation with that meaning would for example
allow us, if we so wish, to support "SELECT S{4} ..." as a simple way to test
the existence of 4 in S (I'm not saying we need to support that, but at least I
think it is a bit early to say we will never support such thing). Lastly, not
reusing the square bracket notation will make it clear that "SET S[4] = 3"
would be non-sensical (if S is a set).
> Support set and map value types in CQL
> --------------------------------------
>
> Key: CASSANDRA-3647
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
