[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396653#comment-13396653
]
Sylvain Lebresne commented on CASSANDRA-3647:
---------------------------------------------
bq. I've been a fan of the status quo since forcing the client to do the read
explicitly makes it clear that you're performing a race-prone sequence.
I suppose it might depends on the definition of race-prone but I would say that
the list operation as implemented are not really race-prone (thanks to the use
of TimeUUID for indices instead of plain integers). In particular I'll not that
the implementation don't "overwrite the entire list with the desired items
removed".
In particular that means that if 2 clients concurrently set elements i and j in
the list, then:
* either i == j, in which case the usual timestamp resolution rules will apply
for element i.
* or i != j, and we guarantee that both update will be taken into account. So
in particular we will *not* potentially lose one of the insert.
I'll note that this is the reason why I don't want to implement a discard by
value for maps: I don't know how to do that without it being clearly race-prone.
Now it is true that if a client reads a list and then tries to set the value at
index i, there is not guarantee this value will still be the ith value, but I
would say that it's mostly us not supporting transactions rather that the list
being race-prone.
Overall I think having set and discard_idx can be useful and have reasonable
behavior in face of concurrency. On the other side, if we ask people to read
and overwrite the whole list, then it will be much more race-prone .
> 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
