Enforcing MySQLdb version(?)
Malcolm Tredinnick
In changeset [4621], Jacob checked in a change to the installation
documents pointing out that we really require the MySQLdb version to be
1.2.1-p2 or later. This is because of a threading bug in earlier
versions.
However, not all systems will be upgraded to that version, since it was
released in April 2006.
Now, as mentioned elsewhere on this list, I would like to apply the
MySQL fixes in #2635. However, they aren't going to work at all on
versions of MySQLdb earlier than 1.2.1. I just tested this -- the wheels
fall right off the wagon if you try to run against 1.2.0. So it makes
sense, if we take these changes to actually not run against earlier
versions and raise an exception.
Which is a better approach?
(A) Don't apply the patch and people running with 1.2.0 or
earlier who have so far been lucky are not visibly affected,
although they may still be getting strange MySQL errors. But
people wanting to use extra table engine, encoding and SQL
strictness options are not going to be able to do so yet.
(B) Apply the patch and people who are using earlier MySQLdb
versions will now see either the exception, or, if we don't
include the version test, completely weird failure modes. This
is probably safer for them, but it's going to be a bit brusque
coming right before the release.
I would probably vote for option A, but I'm really torn here and can
sympathise with both sides.
Thoughts?
Malcolm
Malcolm Tredinnick
[...]
> Which is a better approach?
>
> (A) Don't apply the patch and people running with 1.2.0 or
> earlier who have so far been lucky are not visibly affected,
> although they may still be getting strange MySQL errors. But
> people wanting to use extra table engine, encoding and SQL
> strictness options are not going to be able to do so yet.
>
> (B) Apply the patch and people who are using earlier MySQLdb
> versions will now see either the exception, or, if we don't
> include the version test, completely weird failure modes. This
> is probably safer for them, but it's going to be a bit brusque
> coming right before the release.
I should add: "... and we put a big note in the release notes and on the
backwards compatible page" if we take option (B). I'm not (totally)
heartless.
Malcolm
Michael Radziej
> Which is a better approach?
>
> (A) Don't apply the patch and people running with 1.2.0 or
> earlier who have so far been lucky are not visibly affected,
> although they may still be getting strange MySQL errors. But
> people wanting to use extra table engine, encoding and SQL
> strictness options are not going to be able to do so yet.
>
> (B) Apply the patch and people who are using earlier MySQLdb
> versions will now see either the exception, or, if we don't
> include the version test, completely weird failure modes. This
> is probably safer for them, but it's going to be a bit brusque
> coming right before the release.
>
> I would probably vote for option A, but I'm really torn here and can
> sympathise with both sides.
>
> Thoughts?
(C) Apply the patch with check, but make the unpatched backend
available as mysql-old (just like there are two postgres
backends). Some time in the future, the old backend can be
thrown away.
;-)
I wouldn't fall back to the old backend automatically when the version
check fails, since for many people it's not too difficult to update it.
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
Andy Dustman
MySQL-4.1, and MySQlL-4.1 is the first version with good character set
support (in prior versions the client could not change the character
set) and sub-selects. MySQLdb-1.2.1_p2 has an important bugfix, but it
only matters if you are using MySQL-4.0 or older.
MySQL-4.1.7 was the first production release for 4.1 back in October
2004, and support for 4.1 and 4.0 is limited (you can still buy it,
apparently).
MySQL-5.0.15 was the first production release for 5.0 back in October
2005.
MySQL-5.1 is still beta but will likely be production in the next
couple months.
I would expect most people who are developing produciton websites with
Django (and MySQL) to use Python-2.4 or 2.5 and MySQL-5.0 or possibly
4.1 or 5.1, depending on what they already have deployed. I personally
am using Python-2.4 and MySQL-5.0 and the Django trunk.
There may be some creaky old web hosting setups that still have 4.0 or
possibly older. Even SourceForge, which is not exactly cutting edge,
is using 4.1.
That said, I think if you take the version test out, there's a pretty
good chance that the current patch will work with MySQL-python-1.2.0
and MySQL-4.0 or older.
Malcolm Tredinnick
On Fri, 2007-03-09 at 15:45 +0000, Andy Dustman wrote:
> Also, MySQLdb-1.2.1 is the first version which has support for
> MySQL-4.1, and MySQlL-4.1 is the first version with good character set
> support (in prior versions the client could not change the character
> set) and sub-selects. MySQLdb-1.2.1_p2 has an important bugfix, but it
> only matters if you are using MySQL-4.0 or older.
[.. snip...]
> That said, I think if you take the version test out, there's a pretty
> good chance that the current patch will work with MySQL-python-1.2.0
> and MySQL-4.0 or older.
No, that's one of the problems: I had all sorts of problems cropping up
in the test suite when running with MySQL-python-1.2.0 on a machine I
was testing this on (it was against MySQL 5.0). It essentially didn't
like talking to the database very much. Now that may be because of some
assumptions the test suite makes and it could be worked around by
setting up DATABASE_OPTIONS carefully or something, but it doesn't fill
me with confidence.
Also, the link in http://code.djangoproject.com/ticket/3279#comment:14
seems to indicate there are some real problems with 1.2.0. Or is that
not consistent with your understanding (I know you have quite a history
of MySQL + python work)? So we have set Django's "minimum supported"
version of MySQLdb-python at 1.2.1p2 in the docs, at least. It just
isn't enforced in the code.
Regards,
Malcolm
Michael Radziej
> Also, the link in http://code.djangoproject.com/ticket/3279#comment:14
> seems to indicate there are some real problems with 1.2.0. Or is that
> not consistent with your understanding (I know you have quite a history
> of MySQL + python work)? So we have set Django's "minimum supported"
> version of MySQLdb-python at 1.2.1p2 in the docs, at least. It just
> isn't enforced in the code.
Earlier versions have a multithreading problem, and you cannot use
e.g. fastcgi in threaded mode.
Marek Kubica
On Fri, 09 Mar 2007 20:08:41 +1100, Malcolm Tredinnick wrote:
> I should add: "... and we put a big note in the release notes and on the
> backwards compatible page" if we take option (B). I'm not (totally)
> heartless.
Maybe a warning would be enough? Something like "Django requires MySQLdb
Version X.Y_pZ, older Versions may cause strange errors" might do the
trick. It does not force people to update (which can be hard sometimes)
but tells them what could be causing the problems.
regards,
Marek
Malcolm Tredinnick
We already have a minimum requirement in the installation docs and it
will also probably be in the release notes.
However, the more I think about this the more I think we should be
throwing an error if they are using an older version, particularly in
the new (0.96) release. If you are using the older version you will see
bugs. There is no question about this. It's just dangerous in production
environments. So we should be up front about it.
However, I'm wanting to hear one or hopefully three of other core
developers chime in.
Malcolm
Andy Dustman
> Also, the link in http://code.djangoproject.com/ticket/3279#comment:14
> seems to indicate there are some real problems with 1.2.0.
If there weren't problems, there wouldn't be a 1.2.1. :)
> Or is that
> not consistent with your understanding (I know you have quite a history
> of MySQL + python work)?
It's fair to say I have *all* the history: I've been the developer of
MySQLdb since 1999 (maybe longer).
--
Patriotism means to stand by the country. It does
not mean to stand by the president. -- T. Roosevelt
This message has been scanned for memes and
dangerous content by MindScanner, and is
believed to be unclean.
Jacob Kaplan-Moss
> However, the more I think about this the more I think we should be
> throwing an error if they are using an older version, particularly in
> the new (0.96) release. If you are using the older version you will see
> bugs. There is no question about this. It's just dangerous in production
> environments. So we should be up front about it.
Indeed -- this is how I'd like to see it behave.
Jacob