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. Re: Fran: > 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. > I agree that you might want different behaviour in bigger teams. But I don't think we needd a new setting. If you want to customize the auto-naming, there are enough places you can hook into the process already. I documented three solutions in my blog post. Another place you can directly change the automatic names is in makemigrations.Command.write_migration_files, which receives a dict of app labels to migration objects. You can customize migration.name there (in a custom subclassed command) before calling super() to affect the output names. On Sat, 25 Apr 2020 at 13:36, Fran Hrženjak <fran.hrzen...@gmail.com> wrote: > 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 name is provided > AUTO_NAME_MIGRATIONS = ‘django.db.migrations.suggest_name’ # default value > AUTO_NAME_MIGRATIONS = ‘my.stuff.name_migration’ # custom callable > > 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 me this whole feature feels like a bit on the “advanced” side, so a > custom callable seems more appropriate then too much hand-holding. > > > +1 for “auto_” prefix by default. > > My filename char limit would be 255 :) > > > On Sat, Apr 25, 2020 at 12:08 PM אורי <u...@speedy.net> wrote: > >> >> On Wed, Apr 22, 2020 at 4:06 PM 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. >>>> >>> >> Actually I would prefer all the automatically-generated migration file >> names to be ‘auto’ name with the current date + time, e.g. >> 0002_auto_20200113_1837.py (except the initial migration which could remain >> "0001_initial.py"). I don't think there is a need to name the migrations >> and actually migration names such as "0004_user_has_confirmed_email.py" >> (which is one of our migrations in Speedy Net) makes it look like someone >> named it specifically, although it's also automatically generated by >> Django. Also I prefer the file name to contain the date the migration was >> generated. Most of our migrations, at least 98% I think, were generated >> automatically by running "make_migrations" and I would like to keep it this >> way. Only rarely I would find a need to manually write a migration. 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. >> >> אורי >> >> -- >> 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/CABD5YeEHR6XxPDY_YbdFXW_C9M5JSy3DAwD3FNg%2Bzd-pV%3DSXLw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CABD5YeEHR6XxPDY_YbdFXW_C9M5JSy3DAwD3FNg%2Bzd-pV%3DSXLw%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/CAM2o%3DwMicQZA0PjnvmBSEUyvtAJMDrL19yem3qdPTXXg8M%3D2Sw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAM2o%3DwMicQZA0PjnvmBSEUyvtAJMDrL19yem3qdPTXXg8M%3D2Sw%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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0w%3Dt4V95u%2BZ-FHNMg0QDzGSvy3cBD_pN2gQXj8HQdvSg%40mail.gmail.com.
