Changes between Initial Version and Version 1 of Ticket #31997, comment 6
- Timestamp:
- Sep 12, 2020, 12:29:01 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #31997, comment 6
initial v1 1 1 > But you did not consider the use case which I showed in the "steps to reproduce" section. I believe that it has no potential for data corruption. Don't you agree? 2 2 3 There is, actually - if you wrote that view into a webserver that was getting enough hits per second, the place where you've signalled there would be a HTTP request causes the transactions to then step on each other, since there's a very high chance two requests would be happening at once.3 (edit, after reading again) It doesn't have as high a potential for data corruption, but it's also not really running asynchronously - because {{{create}}} is a blocking synchronous call, it'll hold up the event loop every time it runs, and you've mostly written a fancier for loop. I don't _think_ it would cause corruption, but I'm also not sure if that inner transaction is doing savepoints or pure transactions - if it's doing savepoints because of the outer transaction, then it's absolutely going to run into itself. 4 4 5 5 > In a perfect world, I want Django 3 to always allow all safe use cases and deny all unsafe ones. In a not so perfect world, I want Django 3 to deny all unsafe use cases (even if it denies some safe ones) by default, and to allow all safe use cases (even if it allows some unsafe ones) optionally (not by default, for those who understand what he/she does). This is a fair wish, isn't it?