Re: TransactionManagementError is raised when autocommit …
Hi Tore, > On 05 Mar 2016, at 20:41, Tore Lundqvist 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.
Re: Django Integration
Hi, about the DRF integration in django I went through the dep and the branch of tom christies work. He shared his opinion as some one should do the work and he will provide guidance. I still have some interest in the REST parts work. If Tom christie/DSF core team allows. Thanks Asif On Saturday, March 5, 2016 at 6:16:31 AM UTC+6, Chad Paulson wrote: > > I was happy to read that part of the Mozilla Open Source Support program > funding that was recently awarded to the Django Software Foundation will go > toward integrating key components of Django REST Framework into Django. > > Since I haven't found any update since the initial announcement in > December, I was curious what the status of this integration is and, if > possible, how soon it might be available. > > https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/ > -- 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/c34f919b-788b-4987-aa80-7085f9aefde4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: TransactionManagementError is raised when autocommit …
Hi Tore,
You should be able to get what you want be replacing your commits by
connection.cursor.execute("commit"); transaction.rollback()
or equivalents (caveat: untested).
This looks like a very hackish thing to do, code I wouldn't put in production.
And it should.
Shai.
On Saturday 05 March 2016 21:21:27 Tore Lundqvist wrote:
> Thanks for the suggestion!
> I have been thinking of workarounds with multiple db aliases and it would
> solve the problem I described but in reality the code I'm working with is
> much more complex and has around 400 explicit commits. It all worked great
> in Django 1.4 but since we upgraded to 1.8 (and got the new transaction
> management) I have been forced to make ugly workarounds and patch Django
> this time.
>
> Den lördag 5 mars 2016 kl. 19:41:59 UTC+1 skrev jdunck:
> > I've had this scenario before - you have two interleaving units of work
> > (through composition of code from different sources or concerns). You
> > want progress recorded for one unit of work, but perhaps not the other.
> > Without django, you'd have two open connections. In my experience the
> > simplest way to accommodate this is to have two DB aliases pointed at
> > the same DB. Set one to be a test mirror of the other. Use different
> > aliased connections for the two concerns. Then you can use atomic (as
> > suggested and typical).
> >
> > On Fri, Mar 4, 2016 at 2:11 PM, Tore Lundqvist >
> > > wrote:
> >> I don't what all updates to be in one commit each so I can't wrap just
> >> the update with a atomic block I would need to have it over a bigger
> >> chuck of code. That chunk might call a subrutin that also needs a
> >> commit and if I wrap that update in a atomic block that atomic block is
> >> nested and results in a save point which is useless.
> >>
> >> Den fredag 4 mars 2016 kl. 22:46:30 UTC+1 skrev Aymeric Augustin:
> >>> If you do what Simon and I suggest, you should get the result you just
> >>> described. If you don’t, please explain what happens.
> >>>
> >>> Within a transaction — and disabling autocommit means you’re within a
> >>> transaction — transaction.atomic() uses savepoints.
> >>>
> >>> Note that in Django 1.6, after set_autocommit(False), you couldn’t use
> >>> transaction.atomic(). That was fixed in 1.8 (I think).
> >>>
> >>>
> >>> On 04 Mar 2016, at 21:21, Tore Lundqvist wrote:
> >>>
> >>> Hi, Simon
> >>>
> >>> No, I would need to wrap everything i a atomic block to start the
> >>> transaction and it's only when that outermost atomic block exits that I
> >>> actually get a commit the nested ones just makes save point.
> >>>
> >>> /Tore
> >>>
> >>> Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes:
> Hi Tore,
>
> Is there a reason you can't simply wrap your updates in a
> `transaction.atomic()` blocks?
>
> You should be able to avoid deadlocks and control exactly when data is
> written to disk
> with this construct.
>
> Simon
>
> Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :
> > Reply to comments in ticket:
> > https://code.djangoproject.com/ticket/26323#comment:10
> >
> > Hi,
> >
> > @Aagustin: I get your point but in the code I'm working on there is a
> > lot of transaction.commit(), not to handle transactions but to manage
> > when data is written to disk and to avoid deadlocks. Running in
> > autocommit mode does not work, its slow and sometimes the commits is
> > used to save in a known good state. So I disable autocommit with
> > transaction.set_autocommit(False) and run the code with explicit
> > commits in it and than turn autocommit on again.
> >
> > The documentation for set_autocommit says "Once you turn autocommit
> > off, you get the default behavior of your database adapter, and
> > Django won’t help you." That is what I want and thats way I think
> > that the TransactionManagementError should not de raise if your not
> > using atomic blocks.
> >>
> >> 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-develop...@googlegroups.com .
> >> To post to this group, send email to django-d...@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/79611d30-21e0-45bc-8
> >> ab7-8754a39db4fc%40googlegroups.com
> >> >> -8ab7-8754a39db4fc%40googlegroups.com?utm_medium=email&utm_source=footer
> >> > .
> >>
> >> For more options, visit https://groups.google.com/d/optout.
