Hi Tore, > On 05 Mar 2016, at 20:41, Tore Lundqvist <t...@mima.x.se> wrote: > > Regardless of the particular problem I have got shouldn't it be possible to > disable Djangos transactional management if you want to?
It's possible. It’s documented. https://docs.djangoproject.com/en/1.9/ref/settings/#autocommit https://docs.djangoproject.com/en/1.9/topics/db/transactions/#deactivate-transaction-management > Is not transaction.set_autocommit(False) doing that? It has the same effect as the AUTOCOMMIT option but you have to run it on every new connection. > Is it not surprising to get a TransactionManagementError when you have turned > of the transaction management? As documented, “turning off Django's transaction management” means “you have to understand exactly what happens and, most often, implement yourself a significant part of Django’s transaction management tools”. The ORM still needs to be aware of the current transaction state e.g. for "create or update” operations, for multi-table inserts when inheritance is used, etc. There’s no way to make the ORM not care about transactional integrity at all. > There is also another broken thing with set_autocommit(False) if the database > connection has timed out and is reconnected by Django, autocommit is set to > True again, that was kind of surprising and ugly to workaround. It must be quite frustrating for you to keep ignoring the documentation and the advice given by people who wrote the code, to make up arbitrary theories on Django’s behavior, to realize that this isn’t the actual behavior, and to fantasize that it’s a bug. I’m not sure how we can discuss on such terms. For this discussion to move forwards, you'll have to read and understand the documentation. If you need to go further and get a deeper understanding of how Django ended up there, look at this mailing list’s archives. I explained my reasoning when I implemented Django’s current transaction management in Django 1.6. I explained some choices again in several threads since then. You may also be interested in my DjangoCon talks — the videos are online. I can’t say that the current system is perfect. I know its flaws better than anyone else. However I will say that, until now, you haven't demonstrated a sufficient level of understanding of its design or its implementation to challenge them. I’m sorry for the lack of a good upgrade path. If you read the history, you’ll see why it was impossible to implement adequate transactional integrity guarantees with the old APIs. Perhaps getting this perspective will give you ideas to solves your upgrade problem? (Also, to be honest, given the bugs in the old APIs, I’m skeptical that a system with 400 commit statements in arbitrary locations actually provided the guarantees you hoped for.) In any case, that should give you a better idea of how to use Django’s transaction management APIs and, if they're really unsuitable for your needs, how to do things differently. For what it’s worth, every constructive discussion I’ve had on this topic has resulted in the removal of shaky transaction management code and the implementation of a much more straightforward system based on the new APIs. It’s very hard to help you further without seeing some code. I have very little idea of what problems you’re hitting. I could infer one of your issues when we were discussing on Trac because it’s a common one and, admittedly, a weakness of the current APIs. Then you confirmed it by posting a test case. Unfortunately my crystal ball doesn’t go any further :-( -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/DA565B2F-5C96-42E5-94E8-C13486B5BA8E%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
