#3615: Can't define forward references in fixtures using MySQL with InnoDB
---------------------------------------------------+------------------------
Reporter: russellm | Owner: nobody
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords: mysql
innodb myisam reference fixture
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------
Comment (by ramiro):
I've updated the patch, following notes apply:
* It moves the disabling/enabling of the FK checking from the transaction
infrastructure to the `loaddata` management command. This means the scope
of the fixes this could introduce is limited to fixture loading, I feel a
bit nervous about disabling it in the general case. This means that tests
like `modeltests/mutually_referencial` (where forward references are
introduced through the ORM API instead of doing it through the
serializers) will keep failing for MySQL/InnoDB
* I haven't added the MySQL [http://forge.mysql.com/tools/tool.php?id=11
stored procedure] pointed to by Russell, I tried to implement creating it
in the database programatically but failed miserably. What would need to
be done is to solve that (possibly reducing it's size/complexity by
removing the feature that suggest the SQL code to fix the inconsistencies
found) and try to find the list of tables corresponding to the models
going to be affected by the fixture loading and hand it to the SP when
invoking it after re-enabling the FK checks. Also, perhaps we should first
clear any code licensing doubts about the SQL code fragment.
* A `can_defer_constraint_checks` backend feature has been added to
describe the relevant RDBMS ability. MySQL is the only one with the value
set to False whatever the storage engine in use is, seems `SET
FOREIGN_KEY_CHECKS=X` is a no-op when the storage engine is MyISAM and
wouldn't be worth trying detecting the storage engine in use in the
connection and base `SET FOREIGN_KEY_CHECKS` usage on it because it can
also be set per-table at creation time.
* It includes tests, hopefully `modeltests/fixtures` is the correct place
for them.
SQL Server suffers from similar problems so it would also make use of
`can_defer_constraint_checks=False` feature. But disabling/enabling of
constraint checks is done in a per-table basis by actually executing
explicit `"ALTER <table_name> SET [NO]CHECK CONSTRAINT..."` clauses, I've
written a preliminary implementation for `django-pyodbc` that allows the
loading of fixtures with forward and circular references.
--
Ticket URL: <http://code.djangoproject.com/ticket/3615#comment:6>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
