Russell Keith-Magee wrote: > On Thu, Jun 19, 2008 at 9:04 PM, Peter Melvyn <[EMAIL PROTECTED]> wrote: > >> On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: >> >> >>> (2) provide a way to manually disable and re-enable integrity checks. If >>> someone with more MySQL-fu than me knows how to do either of these >>> >> It should work: >> >> SET FOREIGN_KEY_CHECKS = 0; >> > > Yes - the ticket for this problem (#3615) already has a patch that > uses this technique. > > However, I was under the impression that this has the effect of > disabling, not just deferring key checks - that is, if you disable > checks, load bad data, then re-enable checks, no errors will be > raised. We don't want to be responsible for breaking the referential > integrity of a database, so this isn't a viable solution. > > If I've misunderstood the behaviour of SET FOREIGN_KEY_CHECKS, or you > have any other suggestions, let me know - I'd very much like to put > this bug behind us. > Well I guess the obvious (time consuming, painful) way would be to validate the semantic integrity from Django in the back end. That could, if automated, get horrendously time-consuming for even quite small changes to the database.
Would there be any way to analyze which constraints could be affected by the SQL executed while checks were disabled, so automated checks could be limited to those? Otherwise I'd guess you end up saying "Tough, MySQL is currently broken/less capable". Maybe we could talk to Ted Leung about that? regards Steve --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
