Re: Consider making asgi_rabbitmq an official Django project.

2017-06-10 Thread 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

Fellow Report - June 10, 2017

2017-06-10 Thread 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)

Re: On ASGI...

2017-06-10 Thread 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

Re: Default to BigAutoField

2017-06-10 Thread 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,

Re: Default to BigAutoField

2017-06-10 Thread 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

Re: Default to BigAutoField

2017-06-10 Thread 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

Re: Default to BigAutoField

2017-06-10 Thread 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

Re: Default to BigAutoField

2017-06-10 Thread 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

Re: Default to BigAutoField

2017-06-10 Thread 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

Re: Default to BigAutoField

2017-06-10 Thread 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

Re: Default to BigAutoField

2017-06-10 Thread 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