On Sun, 2007-03-18 at 23:33 +0100, Michael Radziej wrote: > Hi, > > the recent changes in the mysqldb backend require that you use > python-MySQLdb >= 1.2.1p2. Now ... debian sarge has 1.2.1c2, which > cannot be used for django (and the new version check in changeset 3751 > tests it). This will probably break quite a few setups.
Right up until the moment they upgrade MySQLdb, which is required to fix some necessary bugs. :-) This type of problem wasn't out of the range of possibilities, but I seriously don't think it can be a real problem. We (or rather, Django users) have to have realistic expectation about this: If somebody is going to use a distribution like Debian sarge, they are sometimes going to have to upgrade some other small components to fix some problems. Beauty of Open Source is that you can do that. You can't choose a distro that isn't updated very frequently and then say you want to update bits of it frequently without putting in some work. That kind of comes with the territory if you choose Debian "stable" and should not be a surprise to those people. Of slightly more concern to me, but related, is something Jeff Croft pointed out today: the next release will cause problems on Dreamhost, since they are using an older MySQLdb setup. Not a big deal right this minute -- anybody using svn checkouts in production knows the risks they are taking -- but going to be a slightly more visible issue when 0.96 is released. One solution there is for existing Dreamhost customers to ask for an upgrade of that module (pointing out the reasons). The alternative is to install a version of the module locally or test very carefully that the bugs that caused the upgrade do not occur for them and then comment out the version check (benefit of having the source available, again). However, none of these are zero work (although requesting an upgrade by Dreamhost might be close to zero work. Would be good if somebody who's a customer could try that). Obviously the decision to upgrade the minimum requirements wasn't taken without serious consideration, as evidenced by a number of threads on this list. So what are some mitigation steps we could take? There are a few options that spring to mind. (1) work out how to support older versions, (2) carry dual versions, (3) rollback. Considering these in turn... [Option 1:] In order for us to support older versions of MySQLdb in certain setups, we would need somebody to do the following: install MySQL 4.0, 4.1 and 5.0 for testing purposes. Grab a few older versions of MySQLdb (1.2.1p2, 1.2.1c2, maybe a 1.2.0 release). Verify that they can reproduce the bug in #2635 (and the root cause of that problem) under certain setups. Then work out what must change for that problem to go away. In other words, they would come up with the boundaries of the problems we are trying to solve. Without that sort of information, any future changes to the MySQL backend will be uncertain because we won't know if we are tripping over old problems again or not. It rapidly becomes impractical to work like that. By being slightly ahead of the absolute minimal requirements at the moment, we are buying ourselves some room to move. Andy Dustman has mentioned a few times that he thinks the 1.2.1p2 requirement is not necessary for the functionality he put in his improvement patch, at least for later MySQL versions. There's evidence to suggest, thoguh, that at least 1.2.1-final is needed with older MySQL versions (this is supported by the release notes for 1.2.1p2 as well) because of character encoding issues with 1.2.1-gamma. [Option 2:] Carrying dual versions of the MySQL backend, at least for 0.96, may be an alternative. It's less than ideal, because people will be confused into thinking the existing (0.95-release) MySQL backend is in some way supported, so we'll have to answer a lot of queries and tickets about it. In a way, we would be supporting it, but we can't really extend it easily to fix a lot of the problems, which was the real motivation for including Andy's work. [Option 3:] Rollback would be an unfortunate decision. There are a number of internationalisation and support issues with the previous backend code that are made easier to fix (or already fixed) with Andy's patch. I really cannot say enough good things about the work Andy has done here. He proposed a large patch late last year, took comments on board, rewrote it a couple of times, wrote some great documentation to help people get oriented with MySQL+Django (not a dependency of the code patch, but a good addition), fixed a number of problems and has made it much easier for MySQL backend users to control the way they interact with the database server and it's various engines. All in all, I think our lives as maintainers and the ability to work on enhancing the MySQL support are greatly improved because of this change. Unfortunately, MySQL is often treated as a second-class citizen a bit by some of the more experienced Django users and mailing list participants and that isn't fair, given the state it is at today (not 5 or 10 years ago; today!). I would much rather we put the effort into fixing the current code in an acceptable way -- even with some potential backwards compat issues -- than go back to the previous version, which was reasonable for what it did, but had problems going into the future. My preference would be to be to keep the current version requirement (we could remove the code check and document it in big letters, but I've already argued that's a bad idea in another thread) because it fixes real bugs using supported code. Anybody a pre-final release of MySQLdb in production is being slightly less than responsible. I'm just one voice, though. Would be interested to hear others. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
