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: > > 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 > > On Wednesday, August 30, 2017 at 3:49:32 PM UTC-4, Tim Graham wrote: >> >> 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). >> >> On Sunday, August 27, 2017 at 6:51:40 PM UTC-4, Tim Allen wrote: >>> >>> 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. >>> >>> On Saturday, August 26, 2017 at 11:09:42 AM UTC-4, Tim Graham wrote: >>>> >>>> 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 >>>> >>> -- 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+unsubscr...@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/32270039-5be1-401f-9f70-fb083d78cbb7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
