#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 kmtracey):
You are right, it's not a complete solution. Turning foreign key checks
off and then back on lets you introduce integrity errors in the meantime.
A complete solution would incorporate something like that referenced
stored procedure to check what-all had been done during the "defer check"
block and raise an error if there was a constraint violation found.
However, I don't have a whole lot of interest in implementing that myself.
It'd be nice...but if the database itself can't be bothered to do this,
I'm having a hard time working up motivation to devote time to it.
However, if we do provide these routines, we do start to have a hook in
place for saying "here's where the logic needs to go if you want to make
this safer on InnoDB" (or any other DB that does not do deferred
constraint checking).
I did not realize it was a concern that it was very easy to generate
invalid fixtures, and thus not safe for loaddata to simply use this by
default. I can look at changing that, maybe via a flag to loaddata? I
think that was how I originally thought I would approach it but then one
of the other patches just put it in loaddata by default, so I did the
same.
On the deletes, I didn't know how safe it would be to put these inside the
innards of the delete processing, so I just put them in the tests. Since
the tests pass on other, more advanced w.r.t. constraint checking, DBs, I
thought it was safe to bracket the calls in the tests, but didn't know if
it would be safe in general. Since we implement cascading delete manually
I suppose it should be safe...but didn't quite feel comfortable making
that leap myself.
I also did first approach this by just fixing up the new fixtures to not
trip this bug. That's do-able via re-ordering and removing forward
references in the !ManyToManys...but it's error prone, can't be done for
all (e.g. circular) fixtures, has to be re-done if the fixtures are ever
re-generated programmatically, or whenever new ones are introduced...as I
thought about it more and more the list of downsides to that approach got
so long I thought it might be worthwhile trying to do something to address
the underlying problem, even if at this point it isn't a complete answer.
(I did also briefly consider adding checks for the DB in use (there's
already at least one such check) to the tests and issuing the SET
FOREIGN_KEY_CHECKS=0/1 there when necessary, but that is really ugly and
does nothing to help for similar situations on other DBs. As it is it
isn't clear to me if this approach really helps at all for MS SQL Server,
since it apparently wants table names on which to turn off constraint
checking, but maybe someone who knows more (Ramiro?) on that topic can
comment...)
--
Ticket URL: <http://code.djangoproject.com/ticket/3615#comment:9>
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
-~----------~----~----~----~------~----~------~--~---
