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
On 23/04/2020 21:34, Adam Johnson wrote:
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 <and...@aeracode.org
<mailto:and...@aeracode.org>> 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 <m...@adamj.eu
<mailto: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
<mailto: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
<mailto:django-developers+unsubscr...@googlegroups.com>.
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 django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM2HA%2BKPdrnedORUxBvgeAdR-%3DWNb3HvyhsQZgtdbwDnvw%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAMyDDM2HA%2BKPdrnedORUxBvgeAdR-%3DWNb3HvyhsQZgtdbwDnvw%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/d29fe147-9c96-b616-3ef2-a8c419326f4c%40gmail.com.
