Re: Default to BigAutoField

[Adam Johnson]

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 <
> i...@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-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/e3effc41-10e1-42e2-9037-
 84c98217cd91%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.
>>> Visi

Re: drop support for MySQL 5.5 in Django 2.0?

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

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/6a97bf2b-3a90-4f68-ba34-86b39a649d64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.