#26064: Move migration operation reduction logic to their respective class.
-------------------------------------+-------------------------------------
Reporter: charettes | Owner: charettes
Type: | Status: assigned
Cleanup/optimization |
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by charettes):
> To put my skepticism in brief: is it actually easier to write that
reduce method in advance, anticipating all the various schema alterations
that might surround your operation and how you'd return an adjusted
version of your operation to account for them, than it is to just take
care of it manually when squashing? Even if you're using
"squashmigrations" rather than the "full reset" approach, "taking care of
it manually" is just a matter of removing the data migration, adjusting
its successor to point to its parent, then squashing, then re-appending
(and modifying as necessary) the data migration. Squashing is done
infrequently enough that I have a hard time imagining when I'd actually
choose to write and test a fully parametrized operation with a custom
reduce method instead of just doing that manual dance every now and then.
Maybe I just don't use initial-data migrations enough? Or don't squash
frequently enough?
Thanks for your feedback Carl. I agree that for most experienced
developers among us this won't be a game changer. As you said we can
easily figure out where the non-elidable migration has to be moved or how
it should be adjusted.
However I think it can make a significant difference for third-party
applications and large projects where non experienced developers still
have to squash their migrations on their own once there is too many of
them. Such an addition could benefit such users as more experienced
developers could make the whole process a no brainer, the operation would
take care of itself.
For example, the `HStoreExtension` and `HStoreField` case would be a good
candidate for such an addition.
--
Ticket URL: <https://code.djangoproject.com/ticket/26064#comment:7>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.0c67d4ec44afdc962b05520eed4da103%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
