(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
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.
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 c
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 renami
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 Small
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,
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
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 mo
