charettes, thank you for your reply!
The
ATOMIC_REQUESTsetting is not special by any mean, it just manually wrap views in anatomicblocks so I don’t think it warrants special casing. It just happen to a common case that could be problematic.
I assume that the majority of cases when an atomic block wraps read-only queries is when ATOMIC_REQUEST = True. I also assume that if a developer uses transaction.atomic() explicitly, they use it because they are wrapping write queries. This could be a completely wrong assumption on my part, but that is why I thought using IMMEDIATE as a default for transactions.atomic() except for the case when transaction.atomic() is called in the ATOMIC_REQUEST if block that you linked, could be a potential solution.
I do like your solution. I could even wrap it in a PyPI package (as a custom ENGINE) so that people can play around with it and try it out before we make any changes to Django itself.
The only drawback of the OPTIONS solution is that developers would need to know about the option and turn it on, which would only happen after encountering the error. It’s not the best user experience, but it is better than potentially breaking existing code.
I think the reason for not much activity on the original ticket is that making the leap from the db is locked error to I need to use IMMEDIATE is not easy to make. I failed to figure it out a few months back, even though I spent much time debugging the error. My solution ended up being begrugingly switching to Postgres and I only found this solution by chance after Stephen pointed it out in response to my tweet).
I feel that SQLite will continue to build momentum, and it would be great if Django provided a good experience for it out of the box for production like workloads, so whatever I can do to help improve the rough edges I’ll happily do 