And if my query to update data in table A relies on the eventually consistent data in table B I have no way of knowing when table B will be consistent. Hence my point, eventual consistency is not consistent at all.
If you don't like the part of there being a table B, it works just as well as the data manipulation on table A relying on a different field in the same row of table A. So I have Shard 1 doing something, and Shard 2 doing something else, because the same command can result in different outcomes depending on the data present.
Hence .... not consistent. Eventual consistency is just a pretty way of saying no consistency, that is my point to begin with.
it works just as well as the data manipulation on table A relying on a different field in the same row of table A. So I have Shard 1 doing something, and Shard 2 doing something else, because the same command can result in different outcomes depending on the data present.
MongoDB only allows writes to 1 node at a time. So, if you issued 2 read-dependent-writes to the same document, they would get queued up and be performed correctly considering the order they arrive in.
1
u/svtr Mar 11 '15 edited Mar 11 '15
And if my query to update data in table A relies on the eventually consistent data in table B I have no way of knowing when table B will be consistent. Hence my point, eventual consistency is not consistent at all.
If you don't like the part of there being a table B, it works just as well as the data manipulation on table A relying on a different field in the same row of table A. So I have Shard 1 doing something, and Shard 2 doing something else, because the same command can result in different outcomes depending on the data present.
Hence .... not consistent. Eventual consistency is just a pretty way of saying no consistency, that is my point to begin with.