Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?

[Jim Dalton]

I've been trying to do a little work recently on some tickets that related to MySQL-specific issues that come up using Django (#2495 and #3615 specifically). As part of trying to get my head around resolving these, I executed the test suite in the current Django trunk using a MySQL InnoDB backend.

The results weren't pretty. I had to make a few changes to get the tests to even execute (related to a missing "pk" field in regression_tests/admin_views), and once I did I got FAILED (failures=91, errors=219, skipped=21, expected failures=2). It's a bit hard to know where a lot of these are stemming from, but presumably a big chunk relate to the fixture loading problems identified in #3615.

Regardless, it appears that many of these errors have existed across multiple version releases. Also, some of the tickets that relate to these issues are marked as severity normal instead of blocker.

I guess I'd like to understand a bit better what to make of this. Are test failures with the MySQL backend considered acceptable? Do we consider it okay to drop new releases while these issues go unresolved? Is MySQL not considered a fully supported backend?

As I mentioned in a comment recently on #3615, I'd like to get involved in helping move forward on some of these issues (my intent is not to gripe, if that's what it sounds like I'm doing). At the same time, I guess I'd like to have a more clear understanding of the Django developers' commitment to supporting MySQL in the test suite. If this is not something that's considered to be a big deal, or if other decisions have been made on this topic already that I missed, then that's cool. Hopefully someone can shed some light on that if this is the case.

For what it's worth, I haven't come across any serious issues running Django under MySQL in production -- it's all basically related to running the test suite, etc. Still, I'd love to get the test suite for the MySQL backend up to speed because it would make developing and fixing bugs for that backend that much easier.

Thanks for any thoughts on this.

[Jacob Kaplan-Moss]

Hi Jim --

Historically, most Django core developers have been PostgreSQL users
(and advocates to some degree). This has meant that, yes, MySQL
support has lagged behind. It's not that MySQL support isn't
considered important, but it is a matter of priorities. I, at least,
am going to prioritize the database that I actually *use*.

That said, I'm embarrassed by how bad the state of things is (though I
can't reproduce your need-to-modify-the-tests-even-to-get-them-to-run
thing), and we should certainly be doing better. It'll take someone
with the motivation to plink away at the MySQL issues, and I would be
thrilled if that's you.

And yes, if the test suite isn't even *running* that should be
considered a release blocker!

Jacob

[Jim Dalton]

Thanks Jacob. At a minimum, I will at least try to wade through and open a few tickets if they aren't already open and upgrade bugs that are causing test suite errors or failures to release blocker. I did want to make sure I was not overstepping any bounds in assuming those were blockers.

Cheers

Jim

[Andy Dustman]

And if is a real problem in the MySQL support, I'm willing to look
into it. I use it in production. You might have to poke me directly
but I am trying to pay attention lately.

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>

--
Question the answers