3 ms·
Yes but that simplified write complexity means you are pushing a ton of read complexity out to your application.
by callalex 3y ago
Yes but that simplified write complexity means you are pushing a ton of read complexity out to your application.
- winrid 3y agoWhat?? That's an insane argument. That's like saying if one client sets column X to 1 and another client concurrently sets SET y = 2, one client's writes will be LOST. It shouldn't, and it doesn't. If it did, nobody would use Postgres. This issue only exists with PG's JSON impl.
- callalex 3y agoWhat?? That’s an insane way to describe what I’m talking about. Data/transaction isolation is very complex and extremely specific to every use case, which is why database engines worth anything let you describe to them what your needs are. Hence why when one client writes to Y they specify what they think X should be if relevant and get notified to try again if the assumptions are wrong. An advantage of specifying your data and transaction model up front is that it will surface these subtle issues to you before they destructively lose important information in an unrecoverable manner. https://en.wikipedia.org/wiki/Isolation_(database_systems) https://en.wikipedia.org/wiki/Isolation_(database_systems)
- winrid 3y agoSo updating one column on a table is destructive and can lose important information now? :D How do you increment a value in a column while other people write to the database? You don't grab the whole damn row and rewrite it...
- winrid 3y agoAlso this statement: > which is why database engines worth anything let you describe to them what your needs are Contradicts your argument. Mongo has atomic updates to update specific fields, or you can do replaceOne() etc to replace the whole document. While PG only gives you "replace" with JSON. So I guess postgres isn't worth anything. :)