drop support for MySQL 5.5 in Django 2.0?

[Tim Graham]

MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a particular database version in the Django release prior to the end-of-life date [0], so that would mean dropping support in Django 2.1 (released August 2018). We don't have MySQL 5.5 testing in our continuous integration servers and in local testing, I noticed some GIS test failures with MySQL 5.5. Before investigating them, I thought I'd ask to see if there might be consensus to drop support for MySQL 5.5 in Django 2.0 instead of 2.1. I'd guess anyone using MySQL 5.5 users would stick with Django 1.11 LTS or older.

https://github.com/django/django/pull/8980 shows the cleanups for removal of MySQL 5.5 support. Also, MySQL 5.5 is the last usage among the built-in database backends for the supports_microsecond_precision database feature so there's a chance that could be removed also, though I found usage of it in django_pyodbc [1].

[0] https://code.djangoproject.com/wiki/SupportedDatabaseVersions -- though we've made some exceptions like dropping support earlier for Oracle 11, https://groups.google.com/forum/#!topic/django-developers/IawbBWzPXaA/discussion
[1] https://github.com/lionheart/django-pyodbc/issues/87

[Tim Allen]

AFAIK, the supports_microsecond_precision feature is still needed by django-pyodbc-azure, because of SQL Server's, ahem, creative datetime fields.

See: https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/operations.py#L474

There is a fair amount of logic needed (based off of the FreeTDS version and SQL Server version) necessary as well to determine whether to use SQL Server's datetime or datetime2:

https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L80

https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L461

It may be possible to modify django-pyodbc-azure to work another way, but for that I would defer to Michaya. I haven't used any of the other pyodbc forks in years, as django-pyodbc-azure is very well maintained and supports both SQL Server and Azure.

[Tim Graham]

I guess a SQL Server expert will need to interpret https://blogs.msdn.microsoft.com/sqlnativeclient/2008/02/27/microsoft-sql-server-native-client-and-microsoft-sql-server-2008-native-client/ and say exactly which SQL Server versions require the legacy datetime handling. I see django-pyodbc-azure still supports Microsoft SQL Server 2005 (end of extended support was April 2016) and SQL Server 2008/2008R2 (end of mainstream support 2014, end of extended support July 2019). If those are the only SQL Server versions that don't have microsecond support, django-pyodbc-azure might consider dropping support for them -- doubtful if those users require the latest version of Django, I'd guess.

I'm not strictly opposed to keeping the supports_microsecond_precision feature around if it's helpful for that backend, but we'll need contributions from django-pyodbc-azure maintainers to keep it updated (mainly with respect to using the feature to skip or change behavior in tests).

[Collin Anderson]

As a datapoint for MySQL, Most of my websites are on Ubuntu 16.04 (Python 3.5, MySQL 5.7), though I do have one on 14.04 (Python 3.4, MySQL 5.5) that I _would_ upgrade to Django 2.0 if we kept 5.5 support, but it's not a big deal to leave it at 1.11 until I switch to 16.04.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/367b0ca0-1ec9-48b6-a513-4c66a30c491d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Johnson]

Collin, it's also not hard to install MySQL 5.6 from Oracle on Ubuntu 14.04 ;)

Tim, the commit to clean up MySQL 5.5 isn't very big, especially if you put back in the supports_microsecond_precision code. I'm not sure dropping it "prematurely" is that helpful, considering that GIS is rarely used most people won't notice breakage.

That said I'm not using Oracle MySQL that much, so I can't comment on 5.5 prevalence; in fact I work mostly with MariaDB these days.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFO84S7E6Zp284KUKv2NALN3G%2BBUWMxMPPt2uJDFcMtGuz3aig%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Tim Allen]

SQL Server microsecond support (DATETIME2) was first introduced in SQL Server 2008. I can't speak on behalf of Michaya or those maintaining other SQL Server backends, but in our use cases dropping support for 2005 by switching from DATETIME to DATETIME2 exclusively would make sense. That said, we are slowly but surely becoming a PostgreSQL shop, so someone who relies on SQL Server more heavily than us may have further input. The standalone DATE column was also introduced in SQL Server 2008.

I've started a thread here to discuss with Michaya: https://github.com/michiya/django-pyodbc-azure/issues/109

[Michiya Takahashi]

Thank you for letting me know about this and sorry for my delay. I have dropped support for SQL Server 2005 from django-pyodbc-azure since Django 2.0. There is no problem for me to remove  the supports_microsecond_precision database feature from Django 2.

2017年8月31日木曜日 23時45分01秒 UTC+9 Tim Allen: