Re: Add support for multiple file fields

[Tom Forbes]

(I wrote a reply earlier and sent it, but it appears to have disappeared
into /dev/null. Apologies if it comes through at some later date.)

It seems adding a multiple kwarg and retrofitting it onto the existing
FileField might not be the best idea. It might cause confusion with
existing FileField APIs like size and name which don't make sense with
multiple files.

We could add a MultiFileField that had a files attribute, which returns a
list of individual objects analogous to a single FileField?

I guess that MultiFileField could be hidden between a 'multiple' keyword
argument, but I'm not sure a migration from true to false would be possible
which could also be confusing.


On 31 Aug 2017 17:31, "Johannes Hoppe"  wrote:

I tried to exclude my personal opinion and preference from the ticket
description, to have an open discussion.
So here goes my personal opinion:

It seems odd to me that the FileField is limited to 100 characters. I could
not find any reference to why the field was limited in the first place.
Furthermore I do not know of any file system with a 100 char limitation nor
are URLs limited to only 100 chars.

Therefore I would suggest basing the FileField upon the TextField.

I would recommend splitting the issue tho. I would first add support form
multiple files to form. This is a nice feature in itself and requires
little work and good documentation. I would presume that such a feature
would spawn a larger discussion on how to store those files. As multiple
model instances? As an Array in Postgres? As CSV or JSON in a TextField? I
think we can figure this out later or not at all if we don't come to a
conclusion.

I would love to work on that. I do maintain [django-s3file](​https://
github.com/codingjoe/django-s3file/) and [django-stdimage](​https://
github.com/codingjoe/django-stdimage/) and have some experience with custom
the FileInput and FileField. Let me know if I can be of any help.

Cheers
-joe

On Thursday, August 31, 2017 at 6:30:37 PM UTC+2, Johannes Hoppe wrote:
>
> Hi there!
>
> I already created a ticket regarding this matter, but I think this thicket
> requires some discussion prior to crafting a solution.
> https://code.djangoproject.com/ticket/28554
>
> The django.db.models.FileField currently allows only to store a single
> file URL.
> This behavior seems outdated considering that input[type=file] supports a
> multiple attribute, which is supported by all major Browsers.
> See: ​https://www.w3schools.com/tags/att_input_multiple.asp
>
> I would suggest to have a similar attribute on the database field itself,
> as well as on the form field and widget.
>
> The major point for discussion would be how to store the data. The easiest
> would be to coma separate the paths in a single char field. The major
> concern here would be the lack of atomicity. For databases like Postgres I
> would be sensical to use the ArrayField as an underlying structure. Another
> way for serialisation would be the use of JSONs in a char field.
>
> All solutions based on a text or char field have an issue related to the
> compatibility with the current FileField which is limited to 100
> characters. The type would need to be migrated to a text type or the length
> would need to be increased. The latter options bares the question to which
> point.
>
> Another approach would be to defer the storage issue and only provide
> support for multiple files on form level.
> This would mean to add a multiple attribute to the form field and widget.
> Users would be able to create forms with multiple files in a single field
> and handle storage according to their preference.
>
-- 
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/2b9bb49f-1cbc-4ea6-94df-774dfad43114%40googlegroups.
com

.

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

-- 
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 

Re: Add support for multiple file fields

[Johannes Hoppe]

I tried to exclude my personal opinion and preference from the ticket 
description, to have an open discussion.
So here goes my personal opinion:

It seems odd to me that the FileField is limited to 100 characters. I could 
not find any reference to why the field was limited in the first place. 
Furthermore I do not know of any file system with a 100 char limitation nor 
are URLs limited to only 100 chars.

Therefore I would suggest basing the FileField upon the TextField.

I would recommend splitting the issue tho. I would first add support form 
multiple files to form. This is a nice feature in itself and requires 
little work and good documentation. I would presume that such a feature 
would spawn a larger discussion on how to store those files. As multiple 
model instances? As an Array in Postgres? As CSV or JSON in a TextField? I 
think we can figure this out later or not at all if we don't come to a 
conclusion.

I would love to work on that. I do maintain [django-s3file](​
https://github.com/codingjoe/django-s3file/) and [django-stdimage](​
https://github.com/codingjoe/django-stdimage/) and have some experience 
with custom the FileInput and FileField. Let me know if I can be of any 
help.

Cheers
-joe

On Thursday, August 31, 2017 at 6:30:37 PM UTC+2, Johannes Hoppe wrote:
>
> Hi there!
>
> I already created a ticket regarding this matter, but I think this thicket 
> requires some discussion prior to crafting a solution.
> https://code.djangoproject.com/ticket/28554
>
> The django.db.models.FileField currently allows only to store a single 
> file URL.
> This behavior seems outdated considering that input[type=file] supports a 
> multiple attribute, which is supported by all major Browsers.
> See: ​https://www.w3schools.com/tags/att_input_multiple.asp
>
> I would suggest to have a similar attribute on the database field itself, 
> as well as on the form field and widget.
>
> The major point for discussion would be how to store the data. The easiest 
> would be to coma separate the paths in a single char field. The major 
> concern here would be the lack of atomicity. For databases like Postgres I 
> would be sensical to use the ArrayField as an underlying structure. Another 
> way for serialisation would be the use of JSONs in a char field.
>
> All solutions based on a text or char field have an issue related to the 
> compatibility with the current FileField which is limited to 100 
> characters. The type would need to be migrated to a text type or the length 
> would need to be increased. The latter options bares the question to which 
> point.
>
> Another approach would be to defer the storage issue and only provide 
> support for multiple files on form level.
> This would mean to add a multiple attribute to the form field and widget. 
> Users would be able to create forms with multiple files in a single field 
> and handle storage according to their preference.
>

-- 
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/2b9bb49f-1cbc-4ea6-94df-774dfad43114%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Add support for multiple file fields

[Johannes Hoppe]

Hi there!

I already created a ticket regarding this matter, but I think this thicket 
requires some discussion prior to crafting a solution.
https://code.djangoproject.com/ticket/28554

The django.db.models.FileField currently allows only to store a single file 
URL.
This behavior seems outdated considering that input[type=file] supports a 
multiple attribute, which is supported by all major Browsers.
See: ​https://www.w3schools.com/tags/att_input_multiple.asp

I would suggest to have a similar attribute on the database field itself, 
as well as on the form field and widget.

The major point for discussion would be how to store the data. The easiest 
would be to coma separate the paths in a single char field. The major 
concern here would be the lack of atomicity. For databases like Postgres I 
would be sensical to use the ArrayField as an underlying structure. Another 
way for serialisation would be the use of JSONs in a char field.

All solutions based on a text or char field have an issue related to the 
compatibility with the current FileField which is limited to 100 
characters. The type would need to be migrated to a text type or the length 
would need to be increased. The latter options bares the question to which 
point.

Another approach would be to defer the storage issue and only provide 
support for multiple files on form level.
This would mean to add a multiple attribute to the form field and widget. 
Users would be able to create forms with multiple files in a single field 
and handle storage according to their preference.

-- 
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/c08a5bd5-ae4b-49cb-a07a-14c287672a39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Adam Johnson]

I agree with Tim. I also think the rename has potential to mess with
historical migrations, or other uses of the field classes, since the output
of deconstruct() will change the class name.

On 31 August 2017 at 16:13, Tim Graham  wrote:

> Glancing at the PR, one thing I'm not sure about is renaming AutoField to
> SmallAutoField. I think that's going to cause needless additional
> complexity and confusion among people who've worked with Django a long
> time. For example, you might think that "Small" there has a similar meaning
> as SmallIntegerField. Did I miss the discussion about the benefits of the
> rename? If we agree to proceed with it, please split it out into a separate
> ticket/PR for easier review.
>
> On Sunday, August 27, 2017 at 5:31:47 AM UTC-4, Adam Johnson wrote:
>>
>> I don't think "primary key size" is something that's even within
>> consideration for 99% of django apps. Sure a few more bytes are going to be
>> wasted here, but you could argue the same that the default AutoField was
>> already too big for most models that have 100's of instances and could use
>> even a one byte primary key.
>>
>> Defaulting to BigAutoField everywhere is the simple solution that stops
>> everyone from ever worrying about their tables filling up. Additionally
>> using compressed tables helps reclaim nearly all those unused bytes, at
>> least on MySQL.
>>
>> On 18 August 2017 at 17:14, Andrew Godwin  wrote:
>>
>>>
>>>
>>> On Fri, Aug 18, 2017 at 5:43 AM, Markus Holtermann <
>>> in...@markusholtermann.eu> wrote:

 I'm don't fully agree with the approach. This essentially forces 3rd
 party package authors to make the call about the primary key field size.
 While for small to medium size projects BigAutoField is unlikely
 required and only comes with additional (storage) costs. Given that the
 migrations would need to be part of the 3rd party package there's also
 no (trivial) way for project developers to force or change to
 SmallAutoField for those packages. The same thing holds the other way
 round.

 Unfortunately, I don't have another solution at hand.


>>> This is also true of changing the primary key of third-party packages in
>>> general though - e.g. there's no way I can make everything use UUIDs even
>>> if my database would be way better at those.
>>>
>>> I don't see any other solutions that aren't settings doing
>>> spooky-action-at-a-distance to primary keys, and that's something I really
>>> don't want to see.
>>>
>>> Andrew
>>>
>>>

 On Thu, Aug 17, 2017 at 02:43:07PM -0700, Andrew Godwin wrote:

> To elaborate on the solution we eventually came up with - we default
> models
> to use a new BigAutoField that migrations will pick up on and generate
> migrations to alter columns to, but for safety reasons for those that
> don't
> read release notes, made the migration autodetector ask you if you
> want to
> make these migrations with a slowness warning.
>
> It also tells you how to preserve the old behaviour and avoid new
> migrations if you wish (manually set id = SmallAutoField)
>
> I like this approach as it means no new settings or Meta options or
> anything, has a reasonable upgrade path, and won't let people
> unwittingly
> wander into giant changes. The downside is that it does add slightly
> more
> friction to the upgrade process.
>
> Andrew
>
> On Thu, Aug 17, 2017 at 2:36 PM, Kenneth Reitz 
> wrote:
>
> I have opened a pull request:
>>
>> https://github.com/django/django/pull/8924
>>
>> Andrew and I came up with a good solution for migrations, together at
>> DjangoCon.
>>
>> On Wednesday, June 14, 2017 at 7:36:36 AM UTC-7, Melvyn Sopacua wrote:
>>
>>>
>>> On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote:
>>>
>>> > However, it should also be noted that those same larger
>>> applications
>>>
>>> > are the ones that are likely to run into this problem eventually,
>>> so
>>>
>>> > perhaps forcing the migration is the best path moving forward.
>>>
>>>
>>>
>>>
>>>
>>> Existing models are the problem. Then again the database knows the
>>> truth.
>>> So with a little inspection during apps.get_models we might be able
>>> to do
>>> the right thing and even allow migrating in steps.
>>>
>>>
>>>
>>> Apps is also the place to mark an app as migrated.
>>>
>>>
>>>
>>> In fact - couldn't an AppConfig grow a method "get_autoid_type()" and
>>> inject the right one?
>>>
>>>
>>>
>>> You asked fr thoughts, so there's my 2c stream.
>>>
>>> --
>>>
>>> Melvyn Sopacua
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Django developers 

Re: Default to BigAutoField

[Tim Graham]

Glancing at the PR, one thing I'm not sure about is renaming AutoField to 
SmallAutoField. I think that's going to cause needless additional 
complexity and confusion among people who've worked with Django a long 
time. For example, you might think that "Small" there has a similar meaning 
as SmallIntegerField. Did I miss the discussion about the benefits of the 
rename? If we agree to proceed with it, please split it out into a separate 
ticket/PR for easier review.

On Sunday, August 27, 2017 at 5:31:47 AM UTC-4, Adam Johnson wrote:
>
> I don't think "primary key size" is something that's even within 
> consideration for 99% of django apps. Sure a few more bytes are going to be 
> wasted here, but you could argue the same that the default AutoField was 
> already too big for most models that have 100's of instances and could use 
> even a one byte primary key.
>
> Defaulting to BigAutoField everywhere is the simple solution that stops 
> everyone from ever worrying about their tables filling up. Additionally 
> using compressed tables helps reclaim nearly all those unused bytes, at 
> least on MySQL.
>
> On 18 August 2017 at 17:14, Andrew Godwin  > wrote:
>
>>
>>
>> On Fri, Aug 18, 2017 at 5:43 AM, Markus Holtermann <
>> in...@markusholtermann.eu > wrote:
>>>
>>> I'm don't fully agree with the approach. This essentially forces 3rd
>>> party package authors to make the call about the primary key field size.
>>> While for small to medium size projects BigAutoField is unlikely
>>> required and only comes with additional (storage) costs. Given that the
>>> migrations would need to be part of the 3rd party package there's also
>>> no (trivial) way for project developers to force or change to
>>> SmallAutoField for those packages. The same thing holds the other way
>>> round.
>>>
>>> Unfortunately, I don't have another solution at hand.
>>>
>>>
>> This is also true of changing the primary key of third-party packages in 
>> general though - e.g. there's no way I can make everything use UUIDs even 
>> if my database would be way better at those.
>>
>> I don't see any other solutions that aren't settings doing 
>> spooky-action-at-a-distance to primary keys, and that's something I really 
>> don't want to see.
>>
>> Andrew
>>  
>>
>>>
>>> On Thu, Aug 17, 2017 at 02:43:07PM -0700, Andrew Godwin wrote:
>>>
 To elaborate on the solution we eventually came up with - we default 
 models
 to use a new BigAutoField that migrations will pick up on and generate
 migrations to alter columns to, but for safety reasons for those that 
 don't
 read release notes, made the migration autodetector ask you if you want 
 to
 make these migrations with a slowness warning.

 It also tells you how to preserve the old behaviour and avoid new
 migrations if you wish (manually set id = SmallAutoField)

 I like this approach as it means no new settings or Meta options or
 anything, has a reasonable upgrade path, and won't let people 
 unwittingly
 wander into giant changes. The downside is that it does add slightly 
 more
 friction to the upgrade process.

 Andrew

 On Thu, Aug 17, 2017 at 2:36 PM, Kenneth Reitz  wrote:

 I have opened a pull request:
>
> https://github.com/django/django/pull/8924
>
> Andrew and I came up with a good solution for migrations, together at
> DjangoCon.
>
> On Wednesday, June 14, 2017 at 7:36:36 AM UTC-7, Melvyn Sopacua wrote:
>
>>
>> On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote:
>>
>> > However, it should also be noted that those same larger applications
>>
>> > are the ones that are likely to run into this problem eventually, so
>>
>> > perhaps forcing the migration is the best path moving forward.
>>
>>
>>
>>
>>
>> Existing models are the problem. Then again the database knows the 
>> truth.
>> So with a little inspection during apps.get_models we might be able 
>> to do
>> the right thing and even allow migrating in steps.
>>
>>
>>
>> Apps is also the place to mark an app as migrated.
>>
>>
>>
>> In fact - couldn't an AppConfig grow a method "get_autoid_type()" and
>> inject the right one?
>>
>>
>>
>> You asked fr thoughts, so there's my 2c stream.
>>
>> --
>>
>> Melvyn Sopacua
>>
>> --
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 

Re: drop support for MySQL 5.5 in Django 2.0?

[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/1c688f05-1a12-4f59-a77f-34cd36613c1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Trimming in the settings file (Was: Re: Follow-up to #28307: Possible app_template improvements)

[Melvyn Sopacua]

Hi and thanks Aemeric,


On Tue, Jun 27, 2017 at 7:55 AM, Aymeric Augustin
 wrote:
> Hello Melvyn,
>
>> On 26 Jun 2017, at 12:21, Melvyn Sopacua  wrote:
>>
>> keep STATIC_URL (which I rarely change) but remove STATIC_ROOT (which is 
>> different per project and sometimes even per install) is beyond me.
>

> Nowadays it's more common to serve static files from a third-party system 
> such as CloudFront + S3 which doesn't require STATIC_ROOT or with a 
> middleware like whitenoise which doesn't suffer from this concern. Only in 
> the latter case is `STATIC_ROOT = os.path.join(ROOT_DIR, 'static')` a valid 
> default.

Thanks, that clarifies it this specific setting (all though not all
prefer to use services that interfere with SSL trust). But...

> Given this range of options, I still find it best for users to think about 
> what they're doing, read the docs, hopefully review security considerations, 
> define the settings they need and understand their deployment. I also believe 
> that unused settings can be confusing and make it more difficult to diagnose 
> deployment problems.

... this is where we respectively disagree. While it's possible that
things may get clouded, you *can* in fact see what is set.

This:
# DEBUG = False

trumps this:


Also note that if you want things concise, it's much faster to "select
and delete" then "lookup name of setting, copy, paste and alter".

And finally, a diff will show what changed, as opposed to what was
added (which may or may not be a change of the default).

> I'm sure there's a more extensive project template somewhere that will suit 
> your needs better.

Yep, probably should do that and allocate time maintaining it.
-- 
Melvyn Sopacua

-- 
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/CA%2Bgw1GXs6a4GKig%3DUkZFMZZ2v2gmzH1xwTWyKAtTLhwZpzkq0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: drop support for MySQL 5.5 in Django 2.0?

[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.

On 30 August 2017 at 23:01, Collin Anderson  wrote:

> 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.
>
> On Sat, Aug 26, 2017 at 11:09 AM, 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/ms
>> gid/django-developers/367b0ca0-1ec9-48b6-a513-4c66a30c491d%
>> 40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/CAFO84S7E6Zp284KUKv2NALN3G%
> 2BBUWMxMPPt2uJDFcMtGuz3aig%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM27d%2BfUjUskGiP%2B778JcGjgFB85rByKTvFBSuOaGt0Y2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.