#31769: Improve default name of merge migrations.
-------------------------------------+-------------------------------------
Reporter: Jon Dufresne | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Jon Dufresne):
* status: closed => new
* resolution: wontfix =>
Comment:
> I'm not sure about this change because you may need to merge many
migrations. In such case it seems that the timestamp is the best we can do
In the case or merging lots of files, I agree the timestamp is the best we
can do.
To solve this, we can add a threshold for the name length and if exceeded
fallback to the old timestamp naming. This way, the common case of merging
two or three migrations has a more useful name, but it doesn't get out of
hand when more are involved. I'll update the PR with this change and
include a test.
Having a threshold for auto-generated migration names has precedent, so we
can carry that over:
https://github.com/django/django/blob/ae8338daf34fd746771e0678081999b656177bae/django/db/migrations/autodetector.py#L1272
The link uses a length of 100, which I'll use too. But I'm happy to tweak
this larger or smaller to an agreeable size.
I'm also still open to dropping the migration number (`0000_`) if that
makes the filename more readable. I personally like including the number,
but I'm open to alternatives.
> You always use the --name option if you don't like a generated name
Yes. This is the status quo and my current approach. But it doesn't solve
my use case of providing more useful name by default. This is especially
important when working on a diverse team where some members will not
always remember to use useful names. Catching this before the code gets to
team review is helpful for all by reducing repetitive feedback and by
reducing the work a computer can do.
Beyond that, improving the default now means more projects will likely
have more useful and reproducible filenames moving forward, regardless of
their internal standards.
There have recently been a few other PRs, tickets and discussions on
improving migration names. IMO, this ticket is along those same goals:
https://groups.google.com/forum/#!msg/django-
developers/Bmcd779Wdl4/mlQRVNVgAQAJ
https://github.com/django/django/commit/6f3e3e87ab72eb64dcce8e646f8eea07be6c3b7e
--
Ticket URL: <https://code.djangoproject.com/ticket/31769#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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-updates/067.21e0719e0dd9eb8fd2d72a6c16e417d7%40djangoproject.com.
