Django ignores transactions
I am trying to use transaction in Django. It seems that django ignores it. If there is an exception in the block, I expect that the transaction will be rolled back and the DB won't be changed. However, the DB is changed when I query it later.
All my tables are InnoDB. Transactions in mysql-shell work perfectly.
python 2.7.5+, mysql 5.5.54, django 1.8.7.
This is my test code:
Django settings:
DATABASES = {
'my_app': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'my_db',
'USER': ROOT_USER,
'PASSWORD': ROOT_PASS,
'HOST': ROOT_HOST,
'PORT': '3306',
}
}
code:
import django
import os
from django.db import transaction
from my_app.models import Account
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_proj.settings")
django.setup()
with transaction.atomic():
Account.objects.create(account_name='newacc')
raise Exception('no!!!!')
The expected result is that this object will not be in DB after execution.
The real result is that the account is created in DB, although there was an exception.
Even more than that: when debugging the code, when breaking at the 'raise' line, I can see the new object in DB already (using workbench).
python mysql django
asked Apr 10 '17 at 9:06
reformyreformy
5361616
|
show 1 more comment
I am trying to use transaction in Django. It seems that django ignores it. If there is an exception in the block, I expect that the transaction will be rolled back and the DB won't be changed. However, the DB is changed when I query it later.
All my tables are InnoDB. Transactions in mysql-shell work perfectly.
python 2.7.5+, mysql 5.5.54, django 1.8.7.
This is my test code:
Django settings:
DATABASES = {
'my_app': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'my_db',
'USER': ROOT_USER,
'PASSWORD': ROOT_PASS,
'HOST': ROOT_HOST,
'PORT': '3306',
}
}
code:
import django
import os
from django.db import transaction
from my_app.models import Account
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_proj.settings")
django.setup()
with transaction.atomic():
Account.objects.create(account_name='newacc')
raise Exception('no!!!!')
The expected result is that this object will not be in DB after execution.
The real result is that the account is created in DB, although there was an exception.
Even more than that: when debugging the code, when breaking at the 'raise' line, I can see the new object in DB already (using workbench).
python mysql django
asked Apr 10 '17 at 9:06
reformyreformy
5361616
How is this a test of transactions? Transaction is meant to ensure that a set of data modifications happen completely or not at all. We cannot tell how many modificationsAccount.objects.create(account_name='newacc')and you have not even described what the result of the above code was.
– Shadow
Apr 10 '17 at 9:10
@Alasdair It is InnoDB, checked by: SELECT table_name, engine FROM information_schema.tables AS tb WHERE table_schema = 'my_schema';
– reformy
Apr 10 '17 at 9:32
I'm not an expert on python, nor on django, but I thought that the transactions module applied to database level operations, not on python level operations. The exception you raise is on python level and does not affect the database layer, hence there is no rollback.
– Shadow
Apr 10 '17 at 9:32
@Shadow Thanks. However the fact that while debugging I already see the row in DB suggests that this block is not under transaction anyway.
– reformy
Apr 10 '17 at 9:33
@reformy or that the transaction has already been committed, or your isolation level is set to read uncommitted :) What about autocommit settings both on database and django levels?
– Shadow
Apr 10 '17 at 9:40
|
show 1 more comment
I am trying to use transaction in Django. It seems that django ignores it. If there is an exception in the block, I expect that the transaction will be rolled back and the DB won't be changed. However, the DB is changed when I query it later.
All my tables are InnoDB. Transactions in mysql-shell work perfectly.
python 2.7.5+, mysql 5.5.54, django 1.8.7.
This is my test code:
Django settings:
DATABASES = {
'my_app': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'my_db',
'USER': ROOT_USER,
'PASSWORD': ROOT_PASS,
'HOST': ROOT_HOST,
'PORT': '3306',
}
}
code:
import django
import os
from django.db import transaction
from my_app.models import Account
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_proj.settings")
django.setup()
with transaction.atomic():
Account.objects.create(account_name='newacc')
raise Exception('no!!!!')
The expected result is that this object will not be in DB after execution.
The real result is that the account is created in DB, although there was an exception.
Even more than that: when debugging the code, when breaking at the 'raise' line, I can see the new object in DB already (using workbench).
python mysql django
asked Apr 10 '17 at 9:06
reformyreformy
5361616
I am trying to use transaction in Django. It seems that django ignores it. If there is an exception in the block, I expect that the transaction will be rolled back and the DB won't be changed. However, the DB is changed when I query it later.
All my tables are InnoDB. Transactions in mysql-shell work perfectly.
python 2.7.5+, mysql 5.5.54, django 1.8.7.
This is my test code:
Django settings:
DATABASES = {
'my_app': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'my_db',
'USER': ROOT_USER,
'PASSWORD': ROOT_PASS,
'HOST': ROOT_HOST,
'PORT': '3306',
}
}
code:
import django
import os
from django.db import transaction
from my_app.models import Account
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_proj.settings")
django.setup()
with transaction.atomic():
Account.objects.create(account_name='newacc')
raise Exception('no!!!!')
The expected result is that this object will not be in DB after execution.
The real result is that the account is created in DB, although there was an exception.
Even more than that: when debugging the code, when breaking at the 'raise' line, I can see the new object in DB already (using workbench).
python mysql django
python mysql django
asked Apr 10 '17 at 9:06
reformyreformy
5361616
asked Apr 10 '17 at 9:06
reformyreformy
5361616
edited Apr 10 '17 at 9:41
reformy
asked Apr 10 '17 at 9:06
reformyreformy
5361616
asked Apr 10 '17 at 9:06
reformyreformy
5361616
asked Apr 10 '17 at 9:06
reformyreformy
5361616
5361616
How is this a test of transactions? Transaction is meant to ensure that a set of data modifications happen completely or not at all. We cannot tell how many modificationsAccount.objects.create(account_name='newacc')and you have not even described what the result of the above code was.
– Shadow
Apr 10 '17 at 9:10
@Alasdair It is InnoDB, checked by: SELECT table_name, engine FROM information_schema.tables AS tb WHERE table_schema = 'my_schema';
– reformy
Apr 10 '17 at 9:32
I'm not an expert on python, nor on django, but I thought that the transactions module applied to database level operations, not on python level operations. The exception you raise is on python level and does not affect the database layer, hence there is no rollback.
– Shadow
Apr 10 '17 at 9:32
@Shadow Thanks. However the fact that while debugging I already see the row in DB suggests that this block is not under transaction anyway.
– reformy
Apr 10 '17 at 9:33
@reformy or that the transaction has already been committed, or your isolation level is set to read uncommitted :) What about autocommit settings both on database and django levels?
– Shadow
Apr 10 '17 at 9:40
|
show 1 more comment
How is this a test of transactions? Transaction is meant to ensure that a set of data modifications happen completely or not at all. We cannot tell how many modificationsAccount.objects.create(account_name='newacc')and you have not even described what the result of the above code was.
– Shadow
Apr 10 '17 at 9:10
@Alasdair It is InnoDB, checked by: SELECT table_name, engine FROM information_schema.tables AS tb WHERE table_schema = 'my_schema';
– reformy
Apr 10 '17 at 9:32
I'm not an expert on python, nor on django, but I thought that the transactions module applied to database level operations, not on python level operations. The exception you raise is on python level and does not affect the database layer, hence there is no rollback.
– Shadow
Apr 10 '17 at 9:32
@Shadow Thanks. However the fact that while debugging I already see the row in DB suggests that this block is not under transaction anyway.
– reformy
Apr 10 '17 at 9:33
@reformy or that the transaction has already been committed, or your isolation level is set to read uncommitted :) What about autocommit settings both on database and django levels?
– Shadow
Apr 10 '17 at 9:40
How is this a test of transactions? Transaction is meant to ensure that a set of data modifications happen completely or not at all. We cannot tell how many modifications
Account.objects.create(account_name='newacc') and you have not even described what the result of the above code was.– Shadow
Apr 10 '17 at 9:10
How is this a test of transactions? Transaction is meant to ensure that a set of data modifications happen completely or not at all. We cannot tell how many modifications
Account.objects.create(account_name='newacc') and you have not even described what the result of the above code was.– Shadow
Apr 10 '17 at 9:10
@Alasdair It is InnoDB, checked by: SELECT table_name, engine FROM information_schema.tables AS tb WHERE table_schema = 'my_schema';
– reformy
Apr 10 '17 at 9:32
@Alasdair It is InnoDB, checked by: SELECT table_name, engine FROM information_schema.tables AS tb WHERE table_schema = 'my_schema';
– reformy
Apr 10 '17 at 9:32
I'm not an expert on python, nor on django, but I thought that the transactions module applied to database level operations, not on python level operations. The exception you raise is on python level and does not affect the database layer, hence there is no rollback.
– Shadow
Apr 10 '17 at 9:32
I'm not an expert on python, nor on django, but I thought that the transactions module applied to database level operations, not on python level operations. The exception you raise is on python level and does not affect the database layer, hence there is no rollback.
– Shadow
Apr 10 '17 at 9:32
@Shadow Thanks. However the fact that while debugging I already see the row in DB suggests that this block is not under transaction anyway.
– reformy
Apr 10 '17 at 9:33
@Shadow Thanks. However the fact that while debugging I already see the row in DB suggests that this block is not under transaction anyway.
– reformy
Apr 10 '17 at 9:33
@reformy or that the transaction has already been committed, or your isolation level is set to read uncommitted :) What about autocommit settings both on database and django levels?
– Shadow
Apr 10 '17 at 9:40
@reformy or that the transaction has already been committed, or your isolation level is set to read uncommitted :) What about autocommit settings both on database and django levels?
– Shadow
Apr 10 '17 at 9:40
|
show 1 more comment
1 Answer
1
active
oldest
votes
When using transaction.atomic(), one should use the parameter using='my_db_connection' to start the transaction on the relevant DB:
with transaction.atomic(using='my_db_connection'):
In your example:
with transaction.atomic(using='my_app'):
If this argument isn’t provided, Django uses the "default" database connection.
edited Jan 1 at 17:17
Šime Tokić
4791719
answered Apr 10 '17 at 9:44
reformyreformy
5361616
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f43319028%2fdjango-ignores-transactions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
When using transaction.atomic(), one should use the parameter using='my_db_connection' to start the transaction on the relevant DB:
with transaction.atomic(using='my_db_connection'):
In your example:
with transaction.atomic(using='my_app'):
If this argument isn’t provided, Django uses the "default" database connection.
edited Jan 1 at 17:17
Šime Tokić
4791719
answered Apr 10 '17 at 9:44
reformyreformy
5361616
add a comment |
When using transaction.atomic(), one should use the parameter using='my_db_connection' to start the transaction on the relevant DB:
with transaction.atomic(using='my_db_connection'):
In your example:
with transaction.atomic(using='my_app'):
If this argument isn’t provided, Django uses the "default" database connection.
edited Jan 1 at 17:17
Šime Tokić
4791719
answered Apr 10 '17 at 9:44
reformyreformy
5361616
add a comment |
When using transaction.atomic(), one should use the parameter using='my_db_connection' to start the transaction on the relevant DB:
with transaction.atomic(using='my_db_connection'):
In your example:
with transaction.atomic(using='my_app'):
If this argument isn’t provided, Django uses the "default" database connection.
edited Jan 1 at 17:17
Šime Tokić
4791719
answered Apr 10 '17 at 9:44
reformyreformy
5361616
When using transaction.atomic(), one should use the parameter using='my_db_connection' to start the transaction on the relevant DB:
with transaction.atomic(using='my_db_connection'):
In your example:
with transaction.atomic(using='my_app'):
If this argument isn’t provided, Django uses the "default" database connection.
edited Jan 1 at 17:17
Šime Tokić
4791719
answered Apr 10 '17 at 9:44
reformyreformy
5361616
edited Jan 1 at 17:17
Šime Tokić
4791719
edited Jan 1 at 17:17
Šime Tokić
4791719
edited Jan 1 at 17:17
Šime Tokić
4791719
4791719
answered Apr 10 '17 at 9:44
reformyreformy
5361616
answered Apr 10 '17 at 9:44
reformyreformy
5361616
answered Apr 10 '17 at 9:44
reformyreformy
5361616
5361616
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f43319028%2fdjango-ignores-transactions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How is this a test of transactions? Transaction is meant to ensure that a set of data modifications happen completely or not at all. We cannot tell how many modifications
Account.objects.create(account_name='newacc')and you have not even described what the result of the above code was.– Shadow
Apr 10 '17 at 9:10
@Alasdair It is InnoDB, checked by: SELECT table_name, engine FROM information_schema.tables AS tb WHERE table_schema = 'my_schema';
– reformy
Apr 10 '17 at 9:32
I'm not an expert on python, nor on django, but I thought that the transactions module applied to database level operations, not on python level operations. The exception you raise is on python level and does not affect the database layer, hence there is no rollback.
– Shadow
Apr 10 '17 at 9:32
@Shadow Thanks. However the fact that while debugging I already see the row in DB suggests that this block is not under transaction anyway.
– reformy
Apr 10 '17 at 9:33
@reformy or that the transaction has already been committed, or your isolation level is set to read uncommitted :) What about autocommit settings both on database and django levels?
– Shadow
Apr 10 '17 at 9:40