How is this any different than DynamoDB where you specify that you want either eventual consistency vs strong consistency? DDB also does eventual consistent reads by default.
Is the argument that Mongo’s documentation isn’t clear?
"In order to obtain snapshot isolation, users must be careful not only to set the read concern to snapshot for each transaction, but also to set write concern for each transaction to majority. Astonishingly, this applies even to read-only transactions."
"This behavior might be surprising, but to MongoDB’s credit, most of this behavior is clearly laid out in the transactions documentation… MongoDB offers database and collection-level safety settings precisely so users can assume all operations interacting with those databases or collections use those settings; ignoring read and write concern settings when users perform (presumably) safety-critical operations is surprising!"
There is difference between “Mongo’s documentation sucks” and “Mongo is technically deficient”. The former can be corrected by updating the documentation.
Yes, I agree as far as the end user is concerned, they are losing data either way.
I think the implication here is that "Mongo's documentation is deliberately bad in order to hide their technical deficiencies," i.e. they're hoping people will use the defaults, be impressed by the speed, and never realize until it's too late that they're not getting the consistency they were promised.
DynamoDB conditional writes are strongly consistent. Defaulting to inconsistent reads was reckless and I would never defend that, but the worst case is non-repeatable stale results, never lost writes.
That's the right way to disclose a dangerous default, but defaults should be as safe as possible, and users should think very carefully about whether they can get away with opting out. Consistency failures can be very non-intuitive, and hard to clean up after.
So now we shouldn’t ever trust a project because they don’t have good technical writers?
I don’t have a dog in the Mongo fight. I haven’t done an implementation on top of it in years and probably the next time I do something with “Mongo” it will probably be AWS’s Document DB with Mongo support. That’s based on AWS’s own code and storage tier and doesn’t have the same characteristics as Mongo proper.
For what it's worth, Document DB doesn't support a lot of the Mongo API, such as $$ROOT in aggregations, and it can't use indices on (paraphrased) "SELECT * FROM x WHERE id IN [list]" if the list length is > 10.
If you ask me, if there's something worse than Mongo it's Document DB.
Given a choice between the limitations of DynamoDB and DocumentDB, DocumentDB is still far more versatile and written on top of the same storage engine and is just as reliable.
And yes I know most of the data modeling tricks around using GSI’s and LSI’s.
> So now we shouldn’t ever trust a project because they don’t have good technical writers?
> the newer MongoDB 4.2.6 has more problems including “retrocausal transactions” where a transaction reverses order so that a read can see the result of a future write.
Is the argument that Mongo’s documentation isn’t clear?