If you aren't using InnoDB, then it probably doesn't matter if you turn foreign key checks on or off: it becomes a no-op. There are some other storage engines that support transactions, and some of them might "do the right thing" with respect to deferred foreign key checks, but I think it does no harm to disable the checks on loading fixtures on these engines. In other words, always turn them off when loading fixtures (and back on afterwards) and don't care about the storage engine and it should be fine. Keep it simple. On Jul 6, 2011 7:34 PM, "Russell Keith-Magee" <russ...@keith-magee.com> wrote: > > On Thu, Jul 7, 2011 at 5:05 AM, Jim D. <jim.dal...@gmail.com> wrote: > > Are any core devs interested in taking a closer look at the current patch on > > this ticket (https://code.djangoproject.com/ticket/3615)? It's been through > > several rounds of revision after discussion here and on the ticket comment > > thread. > > Interested - most certainly. The issue (as always) is finding the time :-) > > I'm certainly grateful for your efforts; this is a long standing issue > that I'd love to see addressed; I'm just not in a position to commit > to anything. I'll put this on my list of things to look at, but I'm > not getting a whole lot of time to look at that list at the moment. > > > * There's a DB feature can_defer_constraint_checks . I couldn't find much > > by way of documentation or or usage of this feature. But I was trying to > > figure out if the work we are doing here is what this feature refers to, and > > if so, if we should be marking this as True for MySQL and SQLite with this > > implementation. I'm not sure there is other behavior that is required or > > expected in that attribute. Anyhow, that might also be a path forward for > > the issue I raise above (ie. we could skip the test if > > can_defer_constraint_checks is not True). > > This feature flag exists essentially to verify whether MySQL InnoDB is > currently in use. It isn't used during normal runtime; it's purely a > test skipping flag. It's used to identify tests that need to be > skipped because the test data requires a circular reference which > (historically) hasn't been possible under InnoDB because constraints > aren't checked. > > Essentially, this feature flag shouldn't need to exist at all; it only > exists so that InnoDB passes the test suite without errors. If we are > able to resolve the issue that allows MySQL to use forward references > in data, then this feature flag shouldn't be required at all. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. >
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
