#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):
Thanks for the updated patch Ramiro. I'm going to attach another based on
a similar approach but with these differences:
First, instead of having a boolean `can_defer_constraint_checks` and a
pair of routines I just have a pair of routines. I don't see that having
the boolean buys anything, the added routines should just be callable
regardless of what the DB supports and not do any harm if they are not
necessary on the actual DB in use. What to name the routines caused me
some grief....
I did not like `disable_forward_ref_checks` and
`enable_forward_ref_checks` because they seem slightly inaccurate in many
cases. `diaable_forward_ref_checks` actually disables all reference
checks on MySQL/InnoDB, not just forward ones.
`enable_forward_ref_checks` doesn't actually re-enable immediate
constraint checking on Postgres (and I don't think we'd want it to), but
the name sort of implies forward references will be checked (and therefore
cause errors) in code following a call to `enable_forward_ref_checks`.
The names I chose (which aren't necessarily the best, but the best I could
come up with), are `begin_defer_constraint_checks` and
`end_defer_constraint_checks`. They are intended to be placed around code
that requires deferred constraint checking for proper operation -- thus to
be read as a declaration from the programmer about the requirements of the
enclosed code, not necessarily instructions as to what, exactly, the
underlying DB should do to support those requirements. They could be
documented as being database-dependent, likely doing nothing on DBs that
by default support deferred constraint checking, and perhaps disabling all
constraint checking on DBs that don't support deferring constraint
checking. Whether the `end` routine actually implements checking of what
was done in the block would also be implementation-dependent (and not
done, at least initially, for MySQL/InnoDB). (I realize these names are
still a bit inaccurate -- `begin_deferred_constraint_checking_required`
and `end_deferred_constraint_checking_required` would be more accurate but
those (I think) are way too long.)
Second, instead of a new test specifically for this, I adjusted the
existing tests that are failing on InnoDB to make use of the routines.
With the patch I will attach we get a clean run of the Django test suite
on InnoDB. (I'd really like to get something that enables a clean run on
InnoDB because with the addition of the aggregate fixtures that trip this
bug, the amount of "expected" test failure output on InnoDB has become
unmanageable.)
I'm not sure whether/how this approach generalizes to SQL Server. It
sounds like you need to tell it the specific tables involved, and there's
nothing here that does that....?
--
Ticket URL: <http://code.djangoproject.com/ticket/3615#comment:7>
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 django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
