#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 russellm):
Karen - I'm not convinced about this implementation. I looked at using
SET FOREIGN KEY CHECKS=0 back when I opened this ticket, but decided that
it wasn't a complete solution.
As I recall (and I haven't looked into this for a while, so feel free to
correct me), the reason I walked away from the problem was that using SET
FOREIGN_KEY_CHECKS=0 will make the failures in the Django test system go
away, but at the cost of allowing users to completely screw up their
database. If your try to load a badly formed fixture -- for example, a
fixture that contains a foreign key reference to a non-existent object --
and you have foreign key checks turned off, the database doesn't re-
validate when you turn foreign key checks back on. This means you have an
InnoDB table that doesn't have referential integrity, which kind of
defeats one of the reasons for using InnoDB in the first place. Given the
ease with which broken fixtures can be produced, if we're going to turn
this flag on and off automatically, I'd rather see a method that
guaranteed actual referential integrity.
My other comment is whether the calls to defer constraint checks that are
required around calls to delete() should be a manual requirement of the
user (as demonstrated by the test case), or if we should include them as
top and tail calls in Django's delete implementation. Ideally, it would be
nice for InnoDB users to not have to care about the requirements of their
backend of choice. My only hesitation to suggesting this is the potential
for an edge case that requires two (or more) successive calls to delete to
completely purge an object network. I can't think of an obvious example
that wouldn't be cleaned up by Django's normal dependency following delete
logic, but I can't help but think that there might be one.
Of course, the alternative approach to this entire problem is to openly
state that InnoDB's constraint handling is broken, provide the
(potentially dangerous) constraint checking calls as part of MySQL's
operations backend, but make use of those calls _completely_ manual.
Rather than embedding the calls into loaddata, we manually make the calls
in Django's test framework as appropriate, and modify the documentation to
tell InnoDB users that they may need to do the same in their code. It
would be a big hairy wart on the API, but it would allow us to avoid a
class of quite annoying test failures, and provides a solution for InnoDB
users where no solution currently exists.
As for the aggregation test failures - regardless of the design outcome
for this ticket, we may be able to resolve the aggregation test failures
by simply reordering the test fixture. There's nothing in the test fixture
that requires the ordering presented - if we move the list of Authors to
higher in the fixture, most of the serialization problems should go away.
The only potential complication is the list of friends of each author - I
haven't dug into detail to see if there are any circular references, but
even if there are, I don't believe that they are essential for testing
aggregation - we can easily change the test case to remove the circular
dependencies, making the fixture InnoDB friendly.
--
Ticket URL: <http://code.djangoproject.com/ticket/3615#comment:8>
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
-~----------~----~----~----~------~----~------~--~---
