tatterdemalion@programming.dev to Programmer Humor@programming.dev · 1 month agoSQLiteprogramming.devimagemessage-square14linkfedilinkarrow-up1137arrow-down14
arrow-up1133arrow-down1imageSQLiteprogramming.devtatterdemalion@programming.dev to Programmer Humor@programming.dev · 1 month agomessage-square14linkfedilink
minus-squareulterno@programming.devlinkfedilinkEnglisharrow-up0·1 month 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·29 days 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.