On Mon, Jun 27, 2011 at 11:26 PM, Jim D. <jim.dal...@gmail.com> wrote:
> My thinking at this point would be the performance is "good enough" for the > scope of the current ticket, and that if better performance were required or > desired, that could be facilitated under a separate ticket, assuming there > was community demand for it. I agree. I tried that select with a ~1.5 million row referring table crossing tables with ~150,000 and ~17,000 row tables and they completed in less than a second. I think fixing this issue on this backend is well worth adding possibly several seconds to loaddata time there. 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. 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. Thanks for working on this -- wish I'd thought of that idea two years ago! Karen -- 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.
