Hi Dylan,
In my experience, high availability deployments often need to commit model
changes without migration changes. For example, when removing a (nulable)
field, the best approach is to:
1. Remove the field from Django
2. Test
3. Deploy
4. Run makemigrations to generate the migrat
I actually used MonkeyType to generate first version of `django-stubs` back
in the day.
Best regards,
Maxim Kurnikov.
On Thu, Sep 12, 2019 at 11:25 PM Lukas Meier wrote:
> I'm writing here with the risk of you guys obviously already knowing about
> it
>
> there is a project called monkeytype w
Thanks for the tips; I'll take a look at those code paths.
I'm interested in your use case: 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 goe
On Sat, Sep 14, 2019 at 10:09 AM Dylan Young
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 a
>
> I'm interested in your use case: 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?
>
It's not that one *wants* to be in tha
(Fixed Ryan's link: https://github.com/aspiredu/django-safemigrate )
On Sat, 14 Sep 2019 at 17:12, Adam Johnson wrote:
> I'm interested in your use case: 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 a
On Sat, Sep 14, 2019, 12:44 Adam Johnson wrote:
> (Fixed Ryan's link: https://github.com/aspiredu/django-safemigrate )
>
Doh. Thanks.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe fro
Thanks all! I remember reading about the zero downtime deployments many
months back and just needed a refresher. I appreciate it.
To sum up for myself: we need to test at every step of the change that the
model changes are in fact backwards compatible with the old state of the
DB.
Makes sense.
There is no such flag, at least not in 1.11. I wrote my own "migratetest"
and "cleandb" commands because my DBAs don't let me drop and recreate
databases. It is a simple matter if you use the testsuite, but it would
probably be better development to call create_test_db manually and such.
On Fr
