On Jun 28, 2011, at 5:27 AM, Karen Tracey wrote: > Also, though I don't have MySQL 4 handy to test on, I'd be astonished if > there were any issue there compared to MySQL 5. The set foreign_key_check > command is certainly supported in MySLQ 4 and the select being issued to do > the check is nothing special at all.
Agreed. I did find some circumstantial evidence to support the idea that ti would work on MySQL 4 here: http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html#c3009 This comment from 2003 (when MySQL 4 was still in beta) described the technique. If it worked in 2003 I have to imagine we're in good shape. Slightly higher concern is the new get_key_relations() method. Since the information_schema table is not available before MySQL 5 there is a workaround in there for version 4. The contents of this method were originally part of get_indexes() and I just moved them to their own method (that's why you don't see it in the commit). So assuming that function worked fine previously in Django, I don't anticipate this will have a problem either. > > I have not had time to try out the patch, but did look at it. Doesn't the > base implementation of disable_foreign_key_checks need to return False > instead of just passing? The return value is used in loaddata processing to > decide whether it's necessary to re-enable/check. It actually doesn't *need* to return False; pass is the same as not returning anything or returning None. The boolean check just treats it the same way as False. "Should it?" is another question. On the one hand it's a bit more clear, this value is called and always returns False, unless a backend has overridden it. On the other hand, pass is in keeping with other methods in that class that are meant to be overridden in backends, so I went with pass to emphasize that aspect of the code. > > Thanks for working on this -- wish I'd thought of that idea two years ago! You're welcome. It was actually fun to solve a cold case :) -- 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.
