On Sat, Sep 14, 2019 at 10:09 AM Dylan Young <dylanyoungmei...@gmail.com> wrote:
> why do you need the model changes without the migrations? I.e. why would > you want to be in a state that's inconsistent between the ORM and the DB? > Is it just so you can recover more easily if something goes wrong? > I expect that its to allow for shipping the ORM code changes separately from the database migrations. That was my use-case anyway. If the migration needed to run first, then I wanted to deploy the migrations by themselves, then the ORM changes. Sometimes I'd want to ship the ORM changes first, and the migrations later (though usually just running them after deploy was effective). Then when Heroku added release phase, which can automatically run migrations immediately before a release is deployed, I really wanted to do something better. So we created django-safemigrate ( https://github.com/aspiredu/dango-safemigrate), which allows you to mark your deploys as safe to run before, after, or at any time relative to the code changes to the ORM they match. This allows my team to avoid splitting up the ORM changes from the migrations, which keeps matching things together in the commit history. It's been working fairly well for us, barring the occasional human error mis-marking the migrations. Feel free to give it a try, to see if its also a good workflow for you! -- 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/CABpHFHT0OZmKQ%2BfH7%3DSgGCugwVW56QdJ2%2Bgi5ZPXPCH1E%2BF7OA%40mail.gmail.com.
