3 ms·
Hooray, non-repeatable transaction reads in billions of databases where previously that was not an issue! I really hope browsers/apps/etc don't enable this...
by Groxx 3y ago
Hooray, non-repeatable transaction reads in billions of databases where previously that was not an issue!
I really hope browsers/apps/etc don't enable this... but I'm sure many will. A fully sequential database is trivially safe in a way that is absurdly difficult to replicate with concurrency in the mix, and people consistently come to rely on that safety and not realize it.
---
I get the desire, and honestly putting it in sqlite is probably the right choice. With enough care, this seems like a very reasonable set of tradeoffs, and there will almost certainly be good, impactful uses of it. I'm just lamenting the inevitable human decisions this will lead to if it hits the standard feature set, because obviously concurrent is better and faster.
- daveguy 3y agoDo you think possibly they could make it optional and not turned on by default? Like maybe by requiring completely different keywords for concurrent vs non-concurrent?
- Groxx 3y agoI get the sarcasm, but I also run into many, many, many product-team-management and company-wide-infra-decision-making types that mandate concurrency when it is available, and slam it through regardless of the cost. With teams dominated by freshly-graduated-from-college engs. And loads of times that I've seen existing systems hit a performance bottleneck, and the solution was to relax consistency because it speeds up and the existing tests pass. Putting a loaded gun within reach of millions of people is less safe than not doing that.
- valenterry 3y agoSee it positive! I've known too many cases where NoSQL databases where forced upon developers because of HA and concurrency/performance. Now I can at least say "wait, there is concurrency in SQLite if we need it. No problem".
- Groxx 3y agoDefinitely agreed there. More SQLite is more good in my book.