You mean entirely distinct CQL statements issued by the same client
“concurrently”?
If they’re submitted to the same coordinator then M2 will have a higher
timestamp than M1, so if M2 applies first then M1 will be a no-op and should
not generate any view update.
If submitted to different
Perhaps my diagram was not clear. I am starting with mutations on the base
table. I assume they are not bundled together so from separate CQL
statements.
On Fri, Aug 19, 2022 at 11:11 AM Claude Warren, Jr
wrote:
> If each mutation comes from a separate CQL they would be separate, no?
>
>
> On
If each mutation comes from a separate CQL they would be separate, no?
On Fri, Aug 19, 2022 at 10:17 AM Benedict wrote:
> If M1 and M2 both operate over the same partition key they won’t be
> separate mutations, they should be combined into a single mutation before
> submission to SP.mutate
>
If M1 and M2 both operate over the same partition key they won’t be separate
mutations, they should be combined into a single mutation before submission to
SP.mutate
> On 19 Aug 2022, at 10:05, Claude Warren, Jr via dev
> wrote:
>
>
>
> # Table definitions
>
> Table [ Primary key ] other
# Table definitions
Table [ Primary key ] other data
base [ A B C ] D E
MV[ D C ] A B E
# Initial data
base -> MV
[ a b c ] d e -> [d c] a b e
[ a' b c ] d e -> [d c] a' b e
## Mutations -> expected outcome
M1: base [ a b c ] d e' -> MV [ d c ] a b e'
M2: base [ a b c ] d'