Re: Consider making asgi_rabbitmq an official Django project.

[Andrew Godwin]

Hi Artem,

I know we've discussed this privately but I want to put some things on the
public list (and get at least one reply).

My view is that it would be useful to have it maintained, but I do not
personally have the spare time to help maintain it, so it would need at
least one other person to help you maintain it before we could accept it
(they would not have to be existing core, but would need some history of
open-source maintenance)

The other thing would be to see the existing code have more comments and
documentation; currently it has very few comments, in particular.

Andrew

On Thu, Jun 8, 2017 at 9:39 PM, Artem Malyshev  wrote:

> Hi everyone,
>
> asgi_rabbitmq is Channels layer on top of RabbitMQ.  It was originally
> developed as part of Mozilla funding program.
>
> I've complete few major milestones after this.  Now it's used in few
> production systems.  It implements the ASGI specification exactly and
> performs well.
>
> I want to make asgi_rabbitmq an official Django project.
>
> Reasons why I want this happens:
>
> - It will be widely used.  Major changes in the Channels and ASGI will
> take this library into account.
>
> We need:
>
> - Discuss if it's interesting at all for Django project.  Find at least
> one more person who understands library code.  Documentation has a
> comprehensive chapter about internal design and implementation.
>
> Conditions under which I prefer it happens:
>
> - I want to keep commit access for this repository for future development
> and fixes.  - I'll keep it up to date with coming channels releases.  -
> I'll do initial preparation steps for code transfer like code clean up if
> necessary.  But I need receive some comments after code review.
>
> Project repository: https://github.com/proofit404/asgi_rabbitmq
>
> Regards, Artem.
>
> --
> 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/69328d61-68fd-47b8-8f1b-
> a4f0cc85f7cf%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/CAFwN1uqAtsqduLPfikGy7SKT42QMvFZ-M%2Bjem%2BjY04%2BWziMjxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - June 10, 2017

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/28268 - Feature: Clear 
cached_property on related DB operations. (wontfix)

https://code.djangoproject.com/ticket/28276 - debug.py loops over 
QueryDict['items'] instead of QueryDict.items() (duplicate)

https://code.djangoproject.com/ticket/28277 - Validate that annotate() and 
aggregate() args and kwarg values are expressions (created)

https://code.djangoproject.com/ticket/28280 - numberformat.format() 
incorrectly formats large/tiny floats in scientific notation (accepted)

https://code.djangoproject.com/ticket/28283 - _changeform_view sends wrong 
object after ModelForm validation (accepted)

https://code.djangoproject.com/ticket/28289 - QuerySet.count() does not 
with work raw sql annotations on inherited model fields (accepted)

https://code.djangoproject.com/ticket/28292 - ORing on ManyToMany to same 
model can result in duplicate items in queryset (invalid)

https://code.djangoproject.com/ticket/28273 - Document how to prevent 
adding columns with defaults in migrations (accepted)

https://code.djangoproject.com/ticket/28294 - Document request/args/kwargs 
attributes of class-based views (accepted)

https://code.djangoproject.com/ticket/28295 - 
ModelAdmin.prepopulated_fields generates a string with a trailing hyphen 
(accepted)

https://code.djangoproject.com/ticket/28285 - Updating Password Hasher 
Invalidates Users First Login After Upgrade (worksforme)

 

Reviewed/committed

--

https://github.com/django/django/pull/8599 - Fixed #28269 -- Fixed 
Model.__init__() crash on models with a field that has an instance only 
descriptor.

https://github.com/django/django/pull/8598 - Fixed #28262 -- Fixed 
incorrect DisallowedModelAdminLookup when a nested reverse relation is in 
list_filter.

https://github.com/django/django/pull/8600 - Fixed #26651 -- Kept original 
file suffix in TemporaryUploadedFile name.

https://github.com/django/django/pull/8603 - Refs #27795 -- Removed 
force_text() usage in serialization framework.

http://github.com/django/django/pull/8597 - Fixed #28271 -- Added charset 
to technical_500_response() AJAX response.

https://github.com/django/django/pull/8513 - Fixed #28102 -- Doc'd how to 
compute path to built-in widget template directories.

https://github.com/django/django/pull/8596 - Fixed #28202 -- Fixed 
FieldListFilter.get_queryset() crash on invalid input.

https://github.com/django/django/pull/8288 - Fixed #18394 -- Added error 
for invalid JavaScriptCatalog packages.

https://github.com/django/django/pull/8487 - Fixed #28275 -- Added more 
hooks to SchemaEditor_alter_field().

https://github.com/django/django/pull/8468 - Fixed #28104 -- Prevented 
condition decorator from setting ETag/Last-Modified headers for non-safe 
requests.

https://github.com/django/django/pull/8606 - Fixed #28278 -- Fixed invalid 
HTML for a required AdminFileWidget.

https://github.com/django/django/pull/8589 - Fixed #28257 -- Confirmed 
support for GDAL 2.2.

https://github.com/django/django/pull/8567 - Fixed #28233 -- Used a simpler 
example in the aggregation "cheat sheet" docs.

https://github.com/django/django/pull/8537 - Fixed #28232 -- Made raster 
metadata readable and writable on GDALRaster/Band.

https://github.com/django/django/pull/8608 - Fixed #28165 -- Ignored case 
in FileExtensionValidator's allowed_extensions.

https://github.com/django/django/pull/8613 - Fixed #28282 -- Fixed 
class-based indexes name for models that only inherit Model.

https://github.com/django/django/pull/8616 - Fixed #28288 -- Allowed 
passing papsz options to GDALRaster initialization.

https://github.com/django/django/pull/8614 - Fixed #28241 -- Allowed 
module_has_submodule()'s module_name arg to be a dotted path.

https://github.com/django/django/pull/8382 - Fixed #28103 -- Added quarter 
extract, truncation, and lookup.

https://github.com/django/django/pull/8336 - Fixed #27953 -- Added 
instance's pk to Model.__str__().

-- 
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/5265ce57-30e5-4533-ab2b-2471aabbb075%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Andrew Godwin]

On Fri, Jun 9, 2017 at 8:22 PM, Tom Christie  wrote:

> Figure I may as well show the sort of thing I'm thinking wrt. a more
> constrained consumer callable interface...
>
> * A callable, taking two arguments, 'message' & 'channels'
> * Message being JSON-serializable python primitives.
> * Channels being a dictionary of str:channel
> * Channel instances expose `.send()`, `.receive()` and `.name` interfaces.
>
> Extensions such as groups/statistics/flush would get expressed instead as
> channel interfaces,
> eg. a chat example...
>
> def ws_connected(message, channels):
> channels['reply'].send({'accept': True})
> channels['groups'].send({
> 'group': 'chat',
> 'add': channels['reply'].name
> })
>
> def ws_receive(message, channels):
> channels['groups'].send({
> 'group': 'chat',
> 'send': message['text']
> })
>
> def ws_disconnect(message, channels):
> channels['groups'].send({
> 'group': 'chat',
> 'discard': channels['reply'].name
> })
>

So is the channels object just a place to stuff different function
handlers? Why not just pass the channel layer there and use the API on that
directly? e.g.:
   channel_layer.group_send("chat", message["text"])

I was thinking more like:

def handler(channel_layer, channel_name, message):
...

And then frameworks can do per-channel-name dispatch if they like, and use
the channel layer for the send/group methods.


>
> My thinking at the moment is that there isn't any great way of supporting
> both asyncio and sync implementations under the same interface.
> If you're in asyncio land, it makes sense to *only* expose awaitable
> channel operations as you don't ever want to be able to block the task pool.
>
> I think the best you can really do is express two distinct modes of
> interface.
>
> sync: (callable interface, blocking send/receive interface)
> asyncio (coroutine interface, coroutine send/receive interface)
>
> Presumably the equivalent would be true of eg. twisted.
>
> (There's a couple of diff things you can do to bridge from the asyncio
> interface -> sync interface if that's useful)
>

Yup, you can't make cross-compatible ones. This is why ASGI right now has a
receive() method (sync), receive_twisted(), and receive_async(), because
all three have different signatures. I'm hopeful the Twisted and asyncio
ones could be merged, though.

Andrew

-- 
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/CAFwN1uo7n%3DMhuaU2Kv%3D3Vir%3DOHgDxsnB-VXy8A_rSmuxEuczeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Claude Paroz]

Le samedi 10 juin 2017 14:25:49 UTC+2, Curtis Maloney a écrit :

> On 10/06/17 22:21, Claude Paroz wrote: 
> > Another idea would be to offer variants of models.Model which models 
> > could inherit from, like models.BigIntModel or models.UUIDModel. 
>
> Ah, well... now you're talking.  But then, you can do this already as an 
> abstract base with TYPE as id... 
>
> class BigIntModel(models.Model): 
>  id = BigAutoField(primary_key=True) 
>  class Meta: 
>  abstract = True 
>

Absolutely! It would only be a convenience thing. The more I think about 
this, the more I think that it might be addressed by better documentation 
(and maybe some convenience shortcuts). 

-- 
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/d6cbd561-190e-40b5-8419-aac3e42f66b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Curtis Maloney]

On 10/06/17 22:21, Claude Paroz wrote:

Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit :

Right, hence my point of having a global setting to say "the default
auto-field is ..."



I see, but this conforms to the pattern "use the same id field type for
all models of my project". I'm not sure we should encourage that.


Yeah... naming would be key with "DEFAULT_AUTO_FIELD_TYPE" or whatever...


Another idea would be to offer variants of models.Model which models
could inherit from, like models.BigIntModel or models.UUIDModel.


Ah, well... now you're talking.  But then, you can do this already as an 
abstract base with TYPE as id...


class BigIntModel(models.Model):
id = BigAutoField(primary_key=True)
class Meta:
abstract = True


--
C

--
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/a7da67fb-349a-c77c-8324-32dc16bd0ada%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Claude Paroz]

Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit :
>
> Right, hence my point of having a global setting to say "the default 
> auto-field is ..." 
>
> This would: 
> a) ...
>

I see, but this conforms to the pattern "use the same id field type for all 
models of my project". I'm not sure we should encourage that.

Another idea would be to offer variants of models.Model which models could 
inherit from, like models.BigIntModel or models.UUIDModel.

-- 
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/3904d3f9-2ed8-432a-83c3-3bbac1dacc55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Tom Forbes]

I really like the idea of a global configurable setting. One problem with a
setting is that it's not always changeable, which settings kind of imply
(IMO). Going from int->bigint is always possible, but going backwards may
not be, nor might going from int->guid.

I attempted an int->guid migration on one of our systems and ran into some
migrations and postgres-specific issues. Seems like it might be incredibly
difficult to get a simple toggle setting to work with it, and there are
lots of pitfalls.

A warning to the system check framework could be added to check if the
primary key type is changed and potentially incompatible generic foreign
key columns exist. And in the docs rather than use a plain IntegerField,
just use a field that changes based on the setting.

On 10 Jun 2017 10:41, "Curtis Maloney"  wrote:

f) let MySQL users opt for PositiveBigAutoField if they want...



On 10/06/17 19:40, Curtis Maloney wrote:

> Right, hence my point of having a global setting to say "the default
> auto-field is ..."
>
> This would:
> a) let people continue to use AutoField
> b) let people opt for BigAutoField
> c) let 3rd party projects be agnostic
> d) let people use UUIDField(default=uuid.uuid4)
> e) possibly make it feasible to change mid-stream from AutoField to
> BigAutoField...
>
> --
> C
>
> On 10/06/17 19:33, Claude Paroz wrote:
>
>> I think we should first discuss if it makes sense to set a BigAutoField
>> by default for all tables. I'm not convinced of that yet. I looked at my
>> projects with this perspective and found for example a case where I have
>> many small lookup tables (containing between 2-20 entries) for which I
>> know I would never use BigAutoField if I'd design the schema on paper.
>>
>> For me, it's a bit like the `on_delete` parameter for foreign keys. A no
>> "one size fits all" situation.
>> For example, a quick analysis of contrib models (sorry for bad
>> formatting):
>>
>> Model BigAutoField appropriate
>> ===
>> admin.LogEntry yes
>> auth.Userno
>> auth.Group  no
>> auth.Permission no
>> contenttype.ContentType no
>> flatpage.FlatPage  no
>> redirect.Redirectno
>> sessions.Session  yes
>> sites.Site no
>>
>> Shouldn't we treat that issue by better documentation instead?
>> Another idea is to leverage the system check framework (--deploy part)
>> to warn when the max id is over 50% of available range.
>> We are perfectionists, aren't we :-)
>>
>> Claude
>>
>> --
>> 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/0fba4c2c
>> -cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com
>>
>> > c-cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com?utm_medium=
>> email_source=footer>.
>>
>> 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/ms
gid/django-developers/ec59bb2e-bce9-924f-1509-60709a07c5dc%40tinbrain.net.

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/CAFNZOJMntP93kaJ%2BbPuHzAr2rKqZbbSbu1TRc%2Bm%2Bp-%2BiO%2BojvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Curtis Maloney]

f) let MySQL users opt for PositiveBigAutoField if they want...


On 10/06/17 19:40, Curtis Maloney wrote:

Right, hence my point of having a global setting to say "the default
auto-field is ..."

This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
c) let 3rd party projects be agnostic
d) let people use UUIDField(default=uuid.uuid4)
e) possibly make it feasible to change mid-stream from AutoField to
BigAutoField...

--
C

On 10/06/17 19:33, Claude Paroz wrote:

I think we should first discuss if it makes sense to set a BigAutoField
by default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I
know I would never use BigAutoField if I'd design the schema on paper.

For me, it's a bit like the `on_delete` parameter for foreign keys. A no
"one size fits all" situation.
For example, a quick analysis of contrib models (sorry for bad
formatting):

Model BigAutoField appropriate
===
admin.LogEntry yes
auth.Userno
auth.Group  no
auth.Permission no
contenttype.ContentType no
flatpage.FlatPage  no
redirect.Redirectno
sessions.Session  yes
sites.Site no

Shouldn't we treat that issue by better documentation instead?
Another idea is to leverage the system check framework (--deploy part)
to warn when the max id is over 50% of available range.
We are perfectionists, aren't we :-)

Claude

--
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/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%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/ec59bb2e-bce9-924f-1509-60709a07c5dc%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Curtis Maloney]

Right, hence my point of having a global setting to say "the default 
auto-field is ..."


This would:
a) let people continue to use AutoField
b) let people opt for BigAutoField
c) let 3rd party projects be agnostic
d) let people use UUIDField(default=uuid.uuid4)
e) possibly make it feasible to change mid-stream from AutoField to 
BigAutoField...


--
C

On 10/06/17 19:33, Claude Paroz wrote:

I think we should first discuss if it makes sense to set a BigAutoField
by default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I
know I would never use BigAutoField if I'd design the schema on paper.

For me, it's a bit like the `on_delete` parameter for foreign keys. A no
"one size fits all" situation.
For example, a quick analysis of contrib models (sorry for bad formatting):

Model BigAutoField appropriate
===
admin.LogEntry yes
auth.Userno
auth.Group  no
auth.Permission no
contenttype.ContentType no
flatpage.FlatPage  no
redirect.Redirectno
sessions.Session  yes
sites.Site no

Shouldn't we treat that issue by better documentation instead?
Another idea is to leverage the system check framework (--deploy part)
to warn when the max id is over 50% of available range.
We are perfectionists, aren't we :-)

Claude

--
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/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%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/43c2a63f-87de-fda1-87c3-412574c13804%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Claude Paroz]

I think we should first discuss if it makes sense to set a BigAutoField by 
default for all tables. I'm not convinced of that yet. I looked at my 
projects with this perspective and found for example a case where I have 
many small lookup tables (containing between 2-20 entries) for which I know 
I would never use BigAutoField if I'd design the schema on paper.

For me, it's a bit like the `on_delete` parameter for foreign keys. A no 
"one size fits all" situation.
For example, a quick analysis of contrib models (sorry for bad formatting):

Model BigAutoField appropriate
===
admin.LogEntry yes
auth.Userno
auth.Group  no
auth.Permission no
contenttype.ContentType no
flatpage.FlatPage  no
redirect.Redirectno
sessions.Session  yes
sites.Site no

Shouldn't we treat that issue by better documentation instead?
Another idea is to leverage the system check framework (--deploy part) to 
warn when the max id is over 50% of available range.
We are perfectionists, aren't we :-)

Claude

-- 
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/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Default to BigAutoField

[Andrew Godwin]

As long as you changed the actual field that ended up under the "id"
column, then yes, migrations should detect it and apply all the changes
during an upgrade, including to foreign keys.

Generic foreign keys are another problem, however, not to mention the
prospect of how many migrations and ALTER TABLES this would result in on a
large project. We could include in the upgrade notes how to stave it off
(explicitly specify an ID field), but I'm sort of on the fence as to if
that's good enough.

Andrew

On Sat, Jun 10, 2017 at 9:53 AM, Collin Anderson 
wrote:

> I might be wrong, but if the default changes, won't the migrations detect
> it and migrate it just fine, including foreign keys?
>
> All of my migrations have this:
> ('id', models.AutoField(auto_created=True, primary_key=True,
> serialize=False, verbose_name='ID')),
>
> So everyone would either need to manually specify the AutoField to keep
> the old behavior, or run makemigrations to auto-generate migrations to
> BigAutoField. This seems similar to increasing the max_length of
> EmailField, user.username, and user.last_name, though would affect a lot
> more models in this case.
>
> (I'm not sure what I think about the setting idea.)
>
> (While we're at it, maybe we could make it a (new) PositiveBigAutoField to
> help out the mysql folks and close the oldest open ticket:
> https://code.djangoproject.com/ticket/56 :)
>
>
>
> On Fri, Jun 9, 2017 at 9:37 PM, Tim Graham  wrote:
>
>> I'm not sure how this could work with migrations. In a sense, it would
>> involve making the auto-generated primary key "swappable", including
>> foreign keys that point to it. This sounds like a headache.
>>
>> I haven't thought of a possible solution since Kenneth floated this idea
>> in #django-dev yesterday.
>>
>> On Friday, June 9, 2017 at 7:11:05 PM UTC-4, Curtis Maloney wrote:
>>>
>>> I know people hate settings, but what about one for auto id field type?
>>>
>>> It would let you handle backwards compatibility, uuid, and bigint...
>>>
>>> --
>>> C
>>>
>>>
>>> On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss 
>>> wrote:

 I think this would be a good improvement, and I'd like to see it. I've
 been bitten by integers overflowing at least twice I can remember in my
 career, which is two times too many.

 However, a major thing we'd have to work out is the upgrade path
 Consider a simple model:

 class Person(Model):
 name = CharField()

 In Django 1.11, this actually generates a model with an integer `id`
 field. But in we change it, in Django vNext, that `id` field would "turn
 into" a bigint magically without the underlying table changes. That'd be
 confusing: you'd expect the model to be "fixed" by pugrading to vNext, but
 it wouldn't be. I think the migrations engine would detect this as a
 migration (?), so perhaps that's the path forward, but it could still be
 super-confusing. We've never shipped a release of Django that required a
 migration to _all_ your models.

 Have you thought about what the upgrade path should look like, Kenneth?

 Jacob

 On Fri, Jun 9, 2017 at 11:24 AM, Kenneth Reitz 
 wrote:

> Dear Django Dev,
>
>
>
> At Heroku, we have the privilege of seeing an extremely broad range of
> customers utilizing tools like Django to build their applications and
> companies. One of the things that we’ve seen customers hit, time and time
> again when using tools like Django, is integer overflows for primary keys.
> Their application starts behaving unpredictably once they reach the
> overflow, not even knowing such a constraint exists, and they often think
> the problem is with their database provider, rather than with their 
> schema.
> Once they realize what is wrong, it’s a relatively trivial fix, but a
> migration can take several hours to complete, which results in 
> unacceptable
> amounts of downtime.
>
>
>
> Because of this, Heroku, as a company, would like to encourage bigints
> as a sane reasonable default for primary keys for application models. If
> the Django project agrees with this idea, that would mean that Django 
> would
> provide BigAutoField as the default for ‘id’ instead of AutoField.
>
>
>
> Rails made this change recently
> , and has seen
> success in doing so.
>
>
>
> I’m happy to provide the code to do this, but I wanted to discuss it
> here before doing so, to hear what the general consensus was to the
> proposal of such a change.
>
>
>
>
>
> Pros:
>
>-
>
>Users of Django, following the docs, won’t accidentally hit the
>int overflow barrier.
>-
>
>Encourages