tatterdemalion@programming.dev to Programmer Humor@programming.dev · 5 days agoSQLiteprogramming.devimagemessage-square19fedilinkarrow-up1159arrow-down14
arrow-up1155arrow-down1imageSQLiteprogramming.devtatterdemalion@programming.dev to Programmer Humor@programming.dev · 5 days agomessage-square19fedilink
minus-squareulterno@programming.devlinkfedilinkEnglisharrow-up0·3 days ago SQLite puts all of the responsibility on users to handle this Thanks for the explanation. I feel like the one who decided this behaviour, expected the users of the database, to make their own system of prioritising the transactions.
minus-squareF04118F@feddit.nllinkfedilinkarrow-up2·1 day agoMore likely: SQLite is built to be small, simple and lightweight, not to be super highly concurrent. If this situation happens rarely, just make sure you have a retry on the query. If it happens often, switch to postgres.
Thanks for the explanation.
I feel like the one who decided this behaviour, expected the users of the database, to make their own system of prioritising the transactions.
More likely: SQLite is built to be small, simple and lightweight, not to be super highly concurrent.
If this situation happens rarely, just make sure you have a retry on the query. If it happens often, switch to postgres.