#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):
Replying to [comment:9 kmtracey]:
> 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.
This is exactly the reason that I opened this ticket and moved on two
years ago.
> 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.
It's more that I'm not in favor of providing a feature that can silently
lead to a corrupted database. A flag to loaddata sounds like a reasonable
approach though, as long as the option itself is suitably admonishing and
scary (something like --allow-corrupted-databases), with no shortcut
version of the option, and a documentation string that says "make sure you
really need to use this option". It doesn't need to be that name
specifically; I just want to make sure that the user is going to have to
make an active and obvious choice to invoke a call that could have nasty
consequences. This includes implicit calls to loaddata, such as the ones
that happen when test fixtures are loaded.
> 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'm inclined to agree. Given that it will only affect InnoDB users, I see
no problems requiring that users manually call enable/disable if they need
to. This also follows on from the general philosophy of providing the
tools to allow InnoDB to work, but not making it easy to bust things up
completely.
> 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...)
I know absolutely nothing about MSSQL. However, it sounds like we could
make the enable/disable_key_checks() calls take a list of table names.
Postgres/SQlite will do nothing at all in the implementation; MySQL/InnoDB
can ignore the list, but makes the SET call; MSSQL can then make per-table
disable calls as required. It's not pretty, but then nothing about this
whole problem is :-)
--
Ticket URL: <http://code.djangoproject.com/ticket/3615#comment:10>
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
-~----------~----~----~----~------~----~------~--~---
