On Tuesday 22 March 2016 11:57:03 Hugo Chargois wrote: > > I'm unsure that your relentless rant against MySQL is useful in this topic.
I'm sorry if anyone sees it as a rant. It is intended as a technical argument that MySql's REPEATABLE READ is unsuitable for use as a default by Django. > > You're missing the point. First, that same "dance" in user code is nowhere > near as much used as the one in Django internals. As a user, I've never > ever used explicit Django transactions, at all. Have I saved models? Sure. > Loads. Most non-trivial Django projects tie transactions to requests, and don't worry about transactions beyond that. Their authors expect basic, limited consistency guarantees to be gained by that. It is Django's job to try, as best as it can, to fulfill these expectations. > Second, the onus is Django's ORM to get its moves right. It's on me > to get mine right. I know that. I accept that. As a user, that's probably > the most important reason why I'm using an ORM. Because I don't know a lot > about database transactions caveats, and therefore I trust the ORM to do > transactions right and not eat my data. If someday I ever need to do tricky > things and I need to do transactions myself, I will take a hard look on how > transactions work on my database backend, and if I get it wrong, it will be > my fault. I'll answer this argument with an analogy. Imagine that we're back in a world where WSGI doesn't exist, and so Django needs to provide specific adapters to webservers. Further, a specific webserver -- let's call it "MyHttp" -- became very popular, and Django supports it. And then it turns out that, by default, if you try to send a page longer than 16KB on HTTPS, MyHttp instead sends a redirect to HTTP and serves the content unencrypted -- optimizing for using less server resources. A user can prevent that by using some API to declare their application as "sensitive". Consider also that, somehow, this optimization is not very well known. It is explained somewhere within MyHttp's documentation, but the generally known thing is that MyHttp supports HTTPS, although "sometimes there are issues with that". Would you claim that it isn't Django's place to make applications "sensitive" by default? That if users employ MyHttp for secure Django applications, it is their responsibility to find out all about the limitations of their web server, and any expectations not based on reading its whole documentation are irresponsible, and Django shouldn't care? I, for one, expect better of Django. Shai.
