Since this proposal seems to be broadly supported, I've created a
corresponding ticket and pull request:
https://code.djangoproject.com/ticket/31516 and
https://github.com/django/django/pull/12799 .
Thanks all.
On Sat, 25 Apr 2020 at 19:08, Tom Forbes wrote:
> I would be in favour of Adam’s
I would be in favour of Adam’s proposed changes. Adding more context to them
and stripping the appended timestamp would make them more user friendly.
> As a developer I would like to know who generated the code. If a migration is
> auto-generated, I would like to know that. I checked and
On Sat, Apr 25, 2020 at 5:48 PM Adam Johnson wrote:
> Re: Uri:
>
>> If the file name is not like ‘auto’ name with the current date + time, it
>> looks like a migration which was written by a developer.
>>
>
> I think making a distinction between "auto generated" and "hand written"
> migrations
Re: Uri:
> If the file name is not like ‘auto’ name with the current date + time, it
> looks like a migration which was written by a developer.
>
I think making a distinction between "auto generated" and "hand written"
migrations is a bad idea. Django's makemigrations is a code generator, but
as
I’ve been in both situations more than once:
1. wanting to just run makemigrations and never look back,
2. naming each migration and reminding people to do the same.
Small teams / solo = 1, Large teams = 2.
Perhaps a new setting?
AUTO_NAME_MIGRATIONS = None # makemigrations fails if no
On Wed, Apr 22, 2020 at 4:06 PM Adam Johnson wrote:
> Hi djangonauts,
>
> In a blog post earlier this year I outlined my technique to prevent Django
> creating migration files with automatic date names. I had a lot of response
> with other techniques and ended up adding two more techniques to
>
> But I read Andrew's comment differently: it's maybe not the 60 characters,
> but some sort of "aggregation" we could be looking for. So maybe instead of
> "0026_remove_book_title_add_book_description" we could have
> "0026_book_add_remove" - especially when multiple fields were involved.
I
I too am in favour of this change.
But I read Andrew's comment differently: it's maybe not the 60
characters, but some sort of "aggregation" we could be looking for. So
maybe instead of "0026_remove_book_title_add_book_description" we could
have "0026_book_add_remove" - especially when
Thank you all for the feedback.
Re: Andrew:
> (60 is a bit long though, maybe we can bump it down to something a bit
> shorter?)
>
Sure, how about 42?
Re: Jon:
> Did you have a suggestion for this situation? Revert back to auto-naming
> or request the user to name the migration?
>
The
I am a little mixed on this change - the behaviour during the initial
development was indeed to concatenate names like this, albeit only for
adding fields or models; I thought it looked unwieldy, which is why I added
the "auto" name.
That said, the number is the only part that actually matters,
> I'd like to propose using this new full coverage of operation naming to
remove the "auto_MMDD" behaviour
+1 on this proposal. As you've noted in your blog post, I find the default
auto name extremely opaque. Projects I work on normally have an internal
policy to change these names to
I Like the idea of Claude.
Asif
On Wednesday, April 22, 2020 at 7:23:22 PM UTC+6, Claude Paroz wrote:
>
> Le mercredi 22 avril 2020 15:06:12 UTC+2, Adam Johnson a écrit :
>>
>> I'd like to propose using this new full coverage of operation naming to
>> remove the "auto_MMDD" behaviour, and
Le mercredi 22 avril 2020 15:06:12 UTC+2, Adam Johnson a écrit :
>
> I'd like to propose using this new full coverage of operation naming to
> remove the "auto_MMDD" behaviour, and instead always combine
> operations' "suggested migration names" up until a limit of say 60
> characters. I
I think making it possible to customize how migration names are generated has a
great value. Changing something from “auto” to some better/descriptive name has
its value, but I can also see people creating their own strategies for naming
migrations.
I work on a project where migration names
Hi djangonauts,
In a blog post earlier this year I outlined my technique to prevent Django
creating migration files with automatic date names. I had a lot of response
with other techniques and ended up adding two more techniques to the post.
It's at
15 matches
Mail list logo
