Re: drop support for MySQL 5.5 in Django 2.0?

2018-02-10 Thread 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:
>
> 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/djang

Fellow Report - February 2018

2018-02-10 Thread Tim Graham


Week ending February 10, 2018


Triaged

---

https://code.djangoproject.com/ticket/29113 - Simplify 
django.forms.formsets.all_valid() and clarify docstring (fixed)

https://code.djangoproject.com/ticket/29052 - test database setup can 
truncate non-test database if two database aliases point to the same 
database (accepted)

https://code.djangoproject.com/ticket/29115 - Allow rendering of admin 
forms with Jinja2 (accepted)

https://code.djangoproject.com/ticket/29117 - Excessive memory use when 
multiple objects retrieved using objects.get() (duplicate)

https://code.djangoproject.com/ticket/29030 - Make construction of "View on 
site" and "View Site" URLs consistent (accepted)
https://code.djangoproject.com/ticket/29122 - Add a better font for 
Persian/Farsi to the admin (maybe)


Authored

--

https://github.com/django/django/pull/9665 - Refs #28814 -- Fixed 
migrations crash with namespace packages on Python 3.7.

https://github.com/django/django/pull/9672 - Refs #27795 -- Removed 
force_bytes/text() usage in tests.

Reviewed/committed

--

https://github.com/django/django/pull/9657 - Refs #28723 -- Fixed stale 
prefetch_related cache after add/remove.

https://github.com/django/django/pull/8531 - Fixed #27999 -- Added test 
client support for HTTP 307 and 308 redirects.

https://github.com/django/django/pull/9667 - Fixed #28833 -- Prevented 
CacheMiddleware from caching responses with "Cache-Control: private".

https://github.com/django/django/pull/9645 - Fixed #29082 -- Allowed the 
test client to encode JSON request data.

https://github.com/django/django/pull/9538 - Fixed #25790 -- Allowed 
disable column sorting in the admin changelist.

https://github.com/django/django/pull/9235 - Fixed #17419 -- Added json_tag 
template filter.

https://github.com/django/django/pull/9660 - Fixed #29108 -- Fixed crash in 
aggregation of distinct+ordered+sliced querysets.

https://github.com/django/django/pull/9656 - Fixed #29109 -- Fixed the 
admin time picker widget for the Thai locale.

https://github.com/django/django/pull/9671 - Fixed #29118 -- Fixed crash 
with QuerySet.order_by(Exists(...)).

https://github.com/django/django/pull/8528 - Fixed #24747 -- Allowed 
transforms in QuerySet.order_by() and distinct(*fields).
https://github.com/django/django/pull/9560 - Fixed #28960 -- Added 
GEOSGeometry.buffer_with_style().

-- 
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/d686a668-80d7-45f2-97cd-d205b4a1de39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.