Hi, Aymeric Thanks for your extensive reply.
I'm sorry that I just throw in that comment about timed out connections without enough information for you to actually respond to it. an example of when it happens is when: Starting with auto commit on. transaction.set_autocommit(False) ... a lot of time passes without the connection being used so it times out.... close_old_connections() Now autocommit is on again. I'm not saying that it's a bug, but it's inconvenient. I have already seen your talk at DjangoCon and it's very good and I have recommend it to others too. I think the new transaction management API makes a lot more sense than the old one. The problem is that the legacy code uses COMMIT side effects to manage disk writes and avoid deadlocks, securing an adequate transactional integrity is often not an issue. With explicit commit statements it's easy to control when commit is preformed but with atomic blocks you get the commit implicitly when (if they are nested) the outermost block ends, that makes it hard to grantee a commit from deep down a call stack. So I'm trying to disable or at least use as little as possible of Djangos transaction management for this code. Other parts of the system can use the transaction management as intended. Cheers Tore Den söndag 6 mars 2016 kl. 20:25:09 UTC+1 skrev Aymeric Augustin: > > Hi Tore, > > > On 05 Mar 2016, at 20:41, Tore Lundqvist <t...@mima.x.se <javascript:>> > 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/c41072a0-feb7-476a-aa2e-ff2103046898%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
