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, 19 Jun 2012 10:20:44 GMT


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,
* either i == j, in which case the usual timestamp resolution rules will apply for element
* 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:
>             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