You’d run the migrations that you manually created with --fake. My experience also corroborates the idea that squashmigrations may be unsuitable for many situation that are similar to mine, where I am able to fully control the full set of places that the code is deployed.
Ryan > On May 12, 2021, at 11:40 AM, 'Mike Lissner' via Django developers > (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > > Oh, I guess there's also a step in the manual process to reset the migrations > table in the DB, but I don't know how to do that. Tricky stuff! > > On Wednesday, May 12, 2021 at 9:37:53 AM UTC-7 Mike Lissner wrote: > So sort of sounds like an update to the squash migration docs is needed if > this is representative of the general sentiment. Looking at the section on > this > <https://docs.djangoproject.com/en/3.2/topics/migrations/#squashing-migrations>, > the general outline is: > > 1. Overview > 2. How it works > 3. The commands > 4. Gotchas > 5. A bunch of wonky stuff you have to do ("Update all migrations that depend > on the deleted migrations", "Remove the 'replaces' attribute in the Migration > class ") > 6. Another gotcha in an info box > > Would it be a bad idea to update the docs to bifurcate this section so it has > an intro that says something like: > > As you work on your project you will create more and more migrations. When > they get to be too many, there are two approaches to trimming them down. The > first is to use the squashmigrations command and process to create a merged > migration file, however this approach comes with a number of caveats and > gotchas that often make it impractical. The second way is to coordinate with > your team to ensure that all installations of your app are up to date, then > to have a coordinated day when migrations are removed and recreated from > scratch. Which one is best for your organization will depend on the > complexity of your project and the flexibility of your team. > > From there, the docs could go on to explain first how to do this manually, > then move onto the squashmigrations docs. This disfavors squashmigrations by > putting it after the manual approach, but after this conversation (and my > experience) that seems right to me. > > I haven't done the manual approach but I imagine it's something like: > > 1. Check your migrations across all apps with interdependencies for RunPython > or RunSQL code. > 2. If found, make a decision about keeping or deleting that code. > 3. Delete all migrations across all apps that have interdependencies. > 4. Run the makemigrations command > 5. Add your custom RunPython or RunSQL code back > > That'd be a big demotion for the squashmigrations code. I don't know how > married we are to it, but it seems like there's not much energy for making it > better and that lots of people have already demoted it in their minds and > workflows. > > Thanks, > > > Mike > > > > > -- > 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/ce1cb4d6-905f-4411-93df-4449796558a8n%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/ce1cb4d6-905f-4411-93df-4449796558a8n%40googlegroups.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/274F3484-1784-4C0C-8ADC-552E1870C61C%40ryanhiebert.com.
