Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#18116 closed Cleanup/optimization (fixed)

Drop support for MySQL versions < 5.0.3

Reported by: Ramiro Morales Owned by: nobody
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The idea is to drop support of MySQL 4.x (and perhaps 5.0?) for Django 1.5. See:

The first document list the following relevant dates:

  • January 9, 2012 -- Per Oracle's Lifetime Support policy, MySQL 5.0 is now covered under Oracle Sustaining Support.
  • December 31, 2009 -- Per the MySQL Support Lifecycle policy, extended support for MySQL 4.1 ended on December 31, 2009. MySQL users are encouraged to upgrade to a current production release of MySQL. Customers needing upgrade assisitance should contact MySQL Support.
  • December 31, 2009 -- Per the MySQL Support Lifecycle policy, active support for MySQL 5.0 ended on December 31, 2009. MySQL 5.0 is now in the Extended support phase.

Attachments (2)

18116-require-mysql-5.0.3-1.diff (6.2 KB ) - added by Ramiro Morales 13 years ago.
18116-require-mysql-5.0.3-2.diff (8.3 KB ) - added by Ramiro Morales 13 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by Claude Paroz, 13 years ago

Triage Stage: UnreviewedAccepted

Agreed (for 4.x at least).

comment:2 by Ramiro Morales, 13 years ago

Regarding support of enterprise-grade Linux distributions, this is what I've found:

For RHEL, from:

The currently vendor-supported OS version is 5.x that ships MySQL 5.0.y with y > 3.

Any information about versions of MySQL shipped with long-term support of other popular OS is welcome.

comment:3 by Claude Paroz, 13 years ago

In Debian:

In Ubuntu:

comment:4 by Ramiro Morales, 13 years ago

See also #14266.

I would like to propose 5.0.3 as the minimum supported MySQL version.

by Ramiro Morales, 13 years ago

comment:5 by Ramiro Morales, 13 years ago

Has patch: set
Summary: Drop support for older MySQL versionsDrop support for MySQL versions < 5.0.3

The attached patch implements the proposed change. It doesn't actually enforce the minimum version with code, only with the docs. Postgres backend does the same.

comment:6 by Claude Paroz, 13 years ago

Shouldn't the uses_savepoints be set to self._mysql_storage_engine() != 'MyISAM', unless we want to officially drop support for MyISAM?

In introspection.py, I think we can also drop the fallback code in get_key_columns, now that we can count on information_schema table presence.

in reply to:  6 ; comment:7 by Ramiro Morales, 13 years ago

Replying to claudep:

Shouldn't the uses_savepoints be set to self._mysql_storage_engine() != 'MyISAM', unless we want to officially drop support for MyISAM?

Actuall, when the feature got added in r17341 (to fix #15507; ignore the MyIOSAM in the commit message should have read InnoDB) we implemented setting the value of uses_savepoints to depend only the MySQL version (5.0.3) and to be True even when the DB uses MyISAM to avoid having to perform the MySQL storage backend verification (MyISAM v. InnoDB) in normal usage. We perform such test only when running the Django test suite. I'm open to change this but we need to avoid problems like the one reported in #18135.

In introspection.py, I think we can also drop the fallback code in get_key_columns, now that we can count on information_schema table presence.

Thanks for finding this, will update the patch.

by Ramiro Morales, 13 years ago

in reply to:  7 comment:8 by Ramiro Morales, 13 years ago

Replying to ramiro:

Replying to claudep:

Shouldn't the uses_savepoints be set to self._mysql_storage_engine() != 'MyISAM', unless we want to officially drop support for MyISAM?

Actuall, when the feature got added in r17341 (to fix #15507; ignore the MyIOSAM in the commit message should have read InnoDB) we implemented setting the value of uses_savepoints to depend only the MySQL version (5.0.3) and to be True even when the DB uses MyISAM to avoid having to perform the MySQL storage backend verification (MyISAM v. InnoDB) in normal usage. We perform such test only when running the Django test suite. I'm open to change this but we need to avoid problems like the one reported in #18135.

I had forgot why I was reluctant to insert it in the normal non-testing code path. It is because the code that detects of the MySQL storage engine creates a table and examines a query sent afterwards.

I think we should simply set uses_savepoints to True when MySQL >= 5.0.3 and add a note to the savepoints+MySQL documentation directing users using MyISAM to not rely in such Django+MySQL feature.

Last edited 13 years ago by Ramiro Morales (previous) (diff)

comment:9 by Claude Paroz, 13 years ago

Triage Stage: AcceptedReady for checkin

I think this is good to go, thanks.

comment:10 by Ramiro Morales, 13 years ago

Resolution: fixed
Status: newclosed

In [17921]:

Fixed #18116 -- Raised minimum MySQL version officially suported to 5.0.3.

Thanks Carl, Claude and Anssi for discussion and patch review.

comment:11 by Ramiro Morales, 13 years ago

In [17923]:

Added documentation notes about lack of database savepoints support when using MySQL+MyISAM.

Refs #15507, #18116 and r17341, r17921.

Note: See TracTickets for help on using tickets.
Back to Top