2014-10-01 9:21 GMT+02:00 Florian Apolloner :
> Imo, this is mainly useful to rollback if no error occurred! The other use
> of this feature might work but is quite dangerous imo.
>
If you really know what you are doing, it might be possible to use it
safely while taking advantage of a database's
On Wednesday, October 1, 2014 6:58:28 AM UTC+2, Anssi Kääriäinen wrote:
>
> Django does allow to continue the transaction if you explicitly choose
> to do so. After handling the error, you must use set_rollback[1]. This
> is useful for those rare cases where you want to continue after error in
>
On Wednesday, October 1, 2014 6:58:28 AM UTC+2, Anssi Kääriäinen wrote:
>
> Django does allow to continue the transaction if you explicitly choose
> to do so. After handling the error, you must use set_rollback[1]. This
> is useful for those rare cases where you want to continue after error in
>
On Wed, 2014-10-01 at 14:31 +1000, Curtis Maloney wrote:
> This is primarily a function of the DBMS. When your operations cause
> a DB-level error, the DB needs to roll back the transaction to clean
> up.
This depends on the database. On PostgreSQL, after any error the
transaction (or savepoint)
This is primarily a function of the DBMS. When your operations cause a
DB-level error, the DB needs to roll back the transaction to clean up.
If you don't, you're operating on an unknown state.
Django can not control this beyond wrapping the "risky" operation in a
transaction.
Consider -- exact
Hello there,
I have recently updated to django 1.7, from 1.5 and one of the main changes
I had to do was to replace all deprecated transaction.commit_manually to
transaction.atomic, so far so good.
After this, I have found out that if an IntegrityError or DatabaseError
exception happen inside
Hi Christophe, Jacob and all,
On Saturday 23 October 2010, Christophe Pettus wrote:
> On Oct 22, 2010, at 4:01 PM, Jacob Kaplan-Moss wrote:
> > It's a bug: http://code.djangoproject.com/ticket/9964.
> >
> > Looks like the patch there is OK, but still needs some work (there's a
> > couple of TODOs
On Oct 22, 2010, at 4:01 PM, Jacob Kaplan-Moss wrote:
> It's a bug: http://code.djangoproject.com/ticket/9964.
>
> Looks like the patch there is OK, but still needs some work (there's a
> couple of TODOs still).
Looking at the history of the ticket, it looks like there is some concern about
kee
On Oct 22, 2010, at 4:01 PM, Jacob Kaplan-Moss wrote:
> It's a bug: http://code.djangoproject.com/ticket/9964.
>
> Looks like the patch there is OK, but still needs some work (there's a
> couple of TODOs still).
On it! :)
--
-- Christophe Pettus
x...@thebuild.com
--
You received this messa
On Fri, Oct 22, 2010 at 7:01 PM, Jacob Kaplan-Moss wrote:
> On Fri, Oct 22, 2010 at 5:59 PM, Christophe Pettus wrote:
>> Why does transaction management only commit on is_dirty?
>
> It's a bug: http://code.djangoproject.com/ticket/9964.
>
> Looks like the patch there i
On Fri, Oct 22, 2010 at 5:59 PM, Christophe Pettus wrote:
> Why does transaction management only commit on is_dirty?
It's a bug: http://code.djangoproject.com/ticket/9964.
Looks like the patch there is OK, but still needs some work (there's a
couple of TODOs still).
Jacob
--
Why does transaction management only commit on is_dirty?
I realize that the answer to this question is, "Why commit if there are no
changes to the database?", but it's a bit more complicated than that.
Let's assume a reasonably common case:
1. psycopg2 + PostgreSQL.
2. Tr
Hi,
I've got a problem with manual commits for transaction.
Say I have a view function:
@transaction.commit_manually
def index(request):
...
...
object.save()
callOtherFunction()
transaction.commit()
The problem is that I will get a transaction management exception
before ca
13 matches
Mail list logo
