> I'd like to propose using this new full coverage of operation naming to remove the "auto_YYYYMMDD" 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 something more informative. Inevitably, this means there is always a bit of a learning process for new team members. If Django handled this more automatically, it would remove some of this learning process. > and instead always combine operations' "suggested migration names" This sounds reasonable to me. If there is concern about words blending into one another, we could separate them by a double underscore: 0026_remove_book_title__add_book_description. I would personally be fine with either. > up until a limit of say 60 characters Did you have a suggestion for this situation? Revert back to auto-naming or request the user to name the migration? On Wed, Apr 22, 2020 at 6:06 AM Adam Johnson <m...@adamj.eu> 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 django-developers+unsubscr...@googlegroups.com. > 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b4-LHwmKpMTwO2%2BFwLSUCKYwPzwQs28fbH5edPdqjNGRw%40mail.gmail.com.
