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 migration0002_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 tomakemigrations
, 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.
--Personally, I'm against removing auto named migrations. IMO chaining operation names is even more confusing.
--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%40mail.gmail.com.
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
...
Mariusz wrote on the PR:Personally, I'm against removing auto named migrations. IMO chaining operation names is even more confusing.
--
--
(60 is a bit long though, maybe we can bump it down to something a bit shorter?)
Did you have a suggestion for this situation? Revert back to auto-naming or request the user to name the migration?
An alternative could be to ask the user in interactive mode (and keep the current behaviour in non-interactive mode).
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
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1urecp9nGUqwrsxYox%2BtWzv5FcBBWbANg7E9PGAtUG4m_A%40mail.gmail.com.
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 multiple fields were involved.
Alternatively, makemigrations could also generate multiple migrations (by default?) in order to obtain the goal of meaningful names? Have a parameter to force combining?
LP,
Jure
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2HA%2BKPdrnedORUxBvgeAdR-%3DWNb3HvyhsQZgtdbwDnvw%40mail.gmail.com.
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.
Alternatively, makemigrations could also generate multiple migrations (by default?) in order to obtain the goal of meaningful names? Have a parameter to force combining?
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d29fe147-9c96-b616-3ef2-a8c419326f4c%40gmail.com.
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 migration0002_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 tomakemigrations
, but developers often forget this.
--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeEHR6XxPDY_YbdFXW_C9M5JSy3DAwD3FNg%2Bzd-pV%3DSXLw%40mail.gmail.com.
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.
Perhaps a new setting?
...
In this custom callable the developers can decide exactly how to join the suggested names, what is their char limit (60, 42, 254), what to do if char limit is exceeded (raise or fall back to timestamp), etc.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAM2o%3DwMicQZA0PjnvmBSEUyvtAJMDrL19yem3qdPTXXg8M%3D2Sw%40mail.gmail.com.
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 a developer you're still responsible for the code. The autodetector isn't perfect, and perhaps never can be. Even "simple" cases like adding a through table to a ManyToManyField are autodetected "incorrectly" ( a real migration needs SeparateDatabaseAndState https://docs.djangoproject.com/en/3.0/howto/writing-migrations/#changing-a-manytomanyfield-to-use-a-through-model ).I fear marking "auto generated" migrations differently would just encourage (more) lax use of migrations files without reading their content, which invites more risk for data loss and anger with Django for not being perfect.
--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFvWJSotjqhB_L%3Dt9i%3Dx3%3DRt%2Bh-S_gYCAgTV3C8RFMjwg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CC4B31C7-EC63-4531-BF69-3672B9909133%40tomforb.es.