Django - save transactions based on save ()

Question

Since the save () methods of the django model are not lazy , and since saving short transactions is a common practice, it is preferable to save saving until the end of the transaction blocks.

As an example, will code sample B keep the transaction open in less time than code example A below?

Example code A:

from django.db import transaction from my_app.models import MyModel @transaction.commit_on_success def model_altering_method(): for inst in MyModel.objects.all()[0:5000]: inst.name = 'Joel Spolsky' # Some models independent time consuming operations... inst.save() 

Code example B:

 from django.db import transaction from my_app.models import MyModel @transaction.commit_on_success def model_altering_method(): instances_to_save = [] for inst in MyModel.objects.all()[0:5000]: inst.name = 'Joel Spolsky' # Some models independent time consuming operations... instances_to_save.append(inst) for inst in instances_to_save: inst.save() 

Answer 1

The default behavior of Djangos should be performed with an open transaction, which is automatically committed when you call any built-in data modification function. In the case of commit_on_success or commit_manual, django does not execute commit (), but rather successfully executes a function or the transaction.commit () command, respectively.

Thus, an elegant approach would be to separate the transaction processing code and another time code if possible:

 from django.db import transaction from my_app.models import MyModel @transaction.commit_on_success def do_transaction(instances_to_save): for inst in instances_to_save: inst.save() def model_altering_method(): instances_to_save = [] for inst in MyModel.objects.all()[0:5000]: inst.name = 'Joel Spolsky' # Some models independent time consuming operations... instances_to_save.append(inst) do_transaction(instances_to_save) 

If this is impossible constructively, for example. you need the information instance.id, which for new instances you can get only after the first save (), try to split the stream into reasonable sizes of work items, so as not to keep the transaction open for long minutes.

Also note that long transactions are not always bad. If your application is the only entity modifying db, this may actually be normal. However, you should check the specific configuration of your db to see the time limits for transactions (or inaction transactions).

Answer 2

I'm not sure, but here is my theory. I think your commit_manually commit will start a new transaction, and will not have a new spring transaction when you make your first save. So my theory is that sample code B will keep the transaction open longer, as it should scroll the list of models twice.

Again, this is just a theory - and it may also depend on which DBMS you use when a real transaction begins (another theory).