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 patch as-is accumulates suggested names from operations in order, until the length is >=60 characters. Later operations just aren't mentioned. Re: Claude: > An alternative could be to ask the user in interactive mode (and keep the > current behaviour in non-interactive mode). > I'd be up for this if we "pre-fill" the input with the auto-generated name, to make it easy to continue when we can suggest a reasonable name. Forcing users to type a name from scratch could be annoying especially when iterating on a new feature and dropping/rebuilding the respective migration. Re: Caio: > I work on a project where migration names are fixed to âautoâ. We use a > similar technique to those mentioned in the blog post to do that. The > reason is that we want to force developers to get conflicts (git) on > migration names during the review process, rather than having to handle > migration merging manually during deploy Yes, this is a secondary problem with migrations, trying to keep the history linear via git. I've used an alternative solution where a second file is created in the migrations folder called "latest" or similar, that simply contains the name of the latest migration file. This forces a conflict. Although that's an alternative proposal, I think adding something like that to Django could be a good idea. It's better than forcing all migrations to have meaningless names. On Wed, 22 Apr 2020 at 16:47, Andrew Godwin <[email protected]> wrote: > 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, and while > the date is sometimes useful for people to resolve merge conflicts, I don't > think it's better than more informative autogenerated names, so I'm happy > to go with the change. > > (60 is a bit long though, maybe we can bump it down to something a bit > shorter?) > > Andrew > > On Wed, Apr 22, 2020 at 7:06 AM Adam Johnson <[email protected]> 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 >> the post. It's at >> https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/ >> . >> >> The problem with such migration names: >> >> When you run Djangoâs manage.py makemigrations, it will try to generate >>> a name for the migration based upon its contents. For example, if you are >>> adding a single field, it will call the migration >>> 0002_mymodel_myfield.py. However when your migration contains more than >>> one step, it instead uses a simple âautoâ name with the current date + >>> time, e.g. 0002_auto_20200113_1837.py. You can provide the -n/--name >>> argument to makemigrations, but developers often forget this. >>> >>> Naming things is a known hard problem in programming. Having migrations >>> with these automatic names makes managing them harder: You canât tell which >>> is which without opening them, and you could still mix them up if they have >>> similar names due to being generated on the same day. >>> >> Django *currently* sets the migration name to something other than the >> automatic date name in two cases: >> >> - If the migration contains a single operation, it uses a name based >> on that operation, e.g. 00023_remove_model_field, or 0024_add_model_field >> (but not for all operation types) >> - If the migration consists *only* of model creation operations, it >> combines their operation names names, which come as just the lower-cased >> model names e.g. 0025_book_author_sale >> >> I opened a PR to expand the operation naming for the single case to cover >> all built-in operations: https://github.com/django/django/pull/12131 >> >> I'd like to propose using this new full coverage of operation naming to >> remove the "auto_YYYYMMDD" behaviour, and instead always combine >> operations' "suggested migration names" up until a limit of say 60 >> characters. I made a commit for that here: >> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6 >> >> This would lead to migration names such as: >> >> - 0026_remove_book_title_add_book_description >> >> Whilst perhaps long, they're explict and imo easier to work with than the >> auto_YYYYMMDD behaviour. >> >> Mariusz wrote on the PR: >> >> Personally, I'm against removing auto named migrations. IMO chaining >>> operation names is even more confusing. >>> >> -- >> Adam >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAFwN1urecp9nGUqwrsxYox%2BtWzv5FcBBWbANg7E9PGAtUG4m_A%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFwN1urecp9nGUqwrsxYox%2BtWzv5FcBBWbANg7E9PGAtUG4m_A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Adam -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2HA%2BKPdrnedORUxBvgeAdR-%3DWNb3HvyhsQZgtdbwDnvw%40mail.gmail.com.
