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
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)
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
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,
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
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
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
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
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
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
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
11 matches
Mail list logo