[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293431#comment-13293431
]
Sylvain Lebresne commented on CASSANDRA-3647:
---------------------------------------------
bq. If we combined this with the [] syntax for setting a single item, that
would just leave us with discard to solve and we wouldn't need this somewhat
clunky "method call" syntax.
That's definitively an option. One drawback I can think of is that I don't see
how to support both the {{discard}} and {{discard_idx}} methods for lists (at
least for {{list<int>}}), while the clunkier "method call" syntax has no
problem with that. I would almost agree that we could offer only
{{discard_idx}} with no special syntax for {{discard}}, if it wasn't for the
fact that users can't implement {{discard}} as well as we can (because even if
they do a read, they won't have access to the underlying TimeUUID, and thus
would risk to remove the wrong element if there is concurrent update/delete).
{quote}
Maybe some extension to DELETE?
{noformat}
DELETE L[0] FROM foo WHERE ...
DELETE M['asdf'] FROM foo WHERE ...
DELETE S[4] FROM foo WHERE ...
{noformat}
{quote}
I'm not sure I'm convinced by that syntax for sets, as this reuse a very
standard notation for something not standard at all (and I know I suggested a
similar for slice for sets above, but upon further reflexion I don't like it).
It's also related to the {{discard/discard_idx}} problem above since if we find
a "better" syntax for sets, we can reuse it for the discard of lists. That
being said, I don't have a clearly perfect idea. One suggestion would be to use
brackets instead of square brackets, just to make it clear that it selects a
value (so DELETE S{4} FROM ...).
bq. That's pretty tough to explain without leaking implementation details
I absolutely agree and I'm certainly not saying it's not a problem. It's just
that I don't have a solution to that problem, outside of removing the
possibility to "set" a literal at all (which maybe is the right solution).
> 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
