[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293583#comment-13293583
]
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 alternative.
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: 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
