3 ms·
Works for me, so far no data loss after about 150 migrations across 3 projects. These are the settings: @receiver(connection_created) def configure_sqlite(send
by joseferben 3y ago
Works for me, so far no data loss after about 150 migrations across 3 projects. These are the settings:
@receiver(connection_created)
def configure_sqlite(sender, connection, *kwargs):
if connection.vendor == "sqlite":
cursor = connection.cursor()
cursor.execute("PRAGMA journal_mode = WAL;")
cursor.execute("PRAGMA busy_timeout = 5000;")
cursor.execute("PRAGMA synchronous = NORMAL;")
Initially, I was worried that Django might screw up migrations since it's a bit awkward to make certain schema changes in SQLite. Also almost no one seemed to use SQLite with Django in production, so I was a bit worried about how battle tested the SQLite part of the ORM was.
So far so good.
- simonw 3y agoI wrote this about WAL mode with Django and SQLite last year: https://simonwillison.net/2022/Oct/23/datasette-gunicorn/ https://simonwillison.net/2022/Oct/23/datasette-gunicorn/ Your configuration looks right to me.
- joseferben 3y agoThanks for the link. > I asked Django Fellow Carlton Gibson what it would take to update that advice for 2022. Glad to see that SQLite is being presented as a valid option in the current version of the docs. > Even without WAL mode, bumping the SQLite “timeout” option up to 20s solved most of the errors. Can you say anything about the tradeoffs when increasing the timeout, maybe in the context of Django?
- simonw 3y agoI've not explored it in any more depth than I wrote about in that article and my issue comments. My hunch is that if you bump it up to 20s while receiving a huge amount of concurrent traffic you may find yourself running out of available Python workers to serve requests.