[
https://issues.apache.org/jira/browse/CASSANDRA-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-7123:
-----------------------------------
Attachment: 7123-v2.txt
v2 of the patch is the same, except for the bullet point in debate:
bq. If a timestamp is not specified for each operation, then all operations
will be applied with the same timestamp. Due to Cassandra's conflict resolution
procedure in the case of timestamp ties, operations may be applied in an order
that is different from the order they are listed in the @BATCH@ statement. To
force a particular operation ordering, you must specify per-operation
timestamps.
This hints at timestamp ties and conflict resolution being the cause for
unexpected operation ordering, but doesn't mention deletes winning over writes,
or the highest value winning for normal writes. (It should be extremely rare
for somebody to rely on this exact conflict resolution behavior for normal
operations.)
> BATCH documentation should be explicit about ordering guarantees
> ----------------------------------------------------------------
>
> Key: CASSANDRA-7123
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7123
> Project: Cassandra
> Issue Type: Task
> Components: Documentation & website
> Reporter: Tyler Hobbs
> Assignee: Tyler Hobbs
> Priority: Minor
> Attachments: 7123-v2.txt, 7123.txt
>
>
> In the CQL3 [batch statement
> documentation](http://cassandra.apache.org/doc/cql3/CQL.html#batchStmt) we
> don't mention that there are no ordering guarantees, which can lead to
> somewhat surprising behavior (CASSANDRA-6291).
> We should also mention that you could specify timestamps in order to achieve
> a particular ordering.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
