Hi again Russell,
I did a little digging. I'm not sure, but I may have uncovered the problem. A transaction block (using `commit_on_success_unless_managed`) is entered and exited during each fixture object loaded, due to the calls to the aforementioned method that exist in various model methods (namely, `save_base`, in this case). Because of this, the transaction is committed immedately after each object is loaded, despite the attempt to wrap `commit_on_success_unless_managed` around the context of the `loaddata` call in the management command.
The following are the results of my placing print statements (I know that's old-school - pdb is just too time consuming) inside `commit_on_success_unless_managed`. In each call, I added:
print 'AUTOCOMMIT', connection.autocommit
print 'IN ATOMIC BLOCK', connection.in_atomic_block
for frame in inspect.stack():
print frame[1], frame[3], frame[2]
as well as a print after the stack of whether atomic() was returned or _transaction_func() was returned (for easier reading):
AUTOCOMMIT False
IN ATOMIC BLOCK False
django/db/transaction.py commit_on_success_unless_managed 492
django/core/management/commands/loaddata.py handle 53
django/core/management/base.py execute 283
django/core/management/base.py run_from_argv 240
django/core/management/__init__.py execute 392
django/core/management/__init__.py execute_from_command_line 399
manage.py <module> 10
----RETURNING TRANSACTION FUNC
===========================================================
AUTOCOMMIT False
IN ATOMIC BLOCK False
django/db/transaction.py commit_on_success_unless_managed 492
django/db/models/base.py save_base 573
django/core/serializers/base.py save 165
django/core/management/commands/loaddata.py process_dir 225
django/core/management/commands/loaddata.py load_label 169
django/core/management/commands/loaddata.py loaddata 102
django/core/management/commands/loaddata.py handle 54
django/core/management/base.py execute 283
django/core/management/base.py run_from_argv 240
django/core/management/__init__.py execute 392
django/core/management/__init__.py execute_from_command_line 399
manage.py <module> 10
----RETURNING TRANSACTION FUNC
===========================================================
SAVEPOINT False
AUTOCOMMIT True
IN ATOMIC BLOCK False
|||||||||||||||||||||||||||||||||||||||||||||||
django/db/transaction.py commit_on_success_unless_managed 492
django/db/models/base.py save_base 573
django/core/serializers/base.py save 165
django/core/management/commands/loaddata.py process_dir 225
django/core/management/commands/loaddata.py load_label 169
django/core/management/commands/loaddata.py loaddata 102
django/core/management/commands/loaddata.py handle 54
django/core/management/base.py execute 283
django/core/management/base.py run_from_argv 240
django/core/management/__init__.py execute 392
django/core/management/__init__.py execute_from_command_line 399
manage.py <module> 10
----RETURNING ATOMIC
===========================================================
The remaining calls were exactly like call 3 (including "IN ATOMIC BLOCK False", despite the 3rd call having returned `atomic()`). My prima facie opinion is that `with atomic()` is needed in `loaddata`, instead of `with commit_on_success_unless_managed`, since the latter acts funky when nested calls occur (as see in save_base in the stacks printed above). However, the issue might be something that needs to be resolved in the transitioning-to-atomic code. I don't fully understand all of this yet, but it's a start.