Just to add some stats to the conversation, our largest project has ~90
apps (+3rd party), and 240 migration files. This is after we reset our
migration history when migrating from 1.8 -> 1.11 (just over a year ago).
We would have had well in excess of 800 migration files at that point.
To
Migrations are very slow, so I don't run them during test runs, and run
tests with --keepdb even in CI/CD. This is required for my environment
anyway, because we use Oracle heavily, a "schema" is the same thing as a
"user", and is what I used to think of as a "database" coming from MySQL
and
Thanks Adam--the thoroughness of your response makes me more, rather than
less, interested in contributing further to Django. And I must admit you
have me beat on just about all points raised. As a new contributor,
hearing your framing of the consideration that goes into feature requests
was
Thank you for the review, Adam.
I like the idea of the post-migrate signal, but it can be complicated, and
sometimes doing things in sequence is important:
With Oracle, if function B runs function A (and so on) then after we run:
CREATE OR REPLACE FUNCTION *A*(...)
We would need to, in
Hi Brad,
I appreciate no one has replied here for some time, and your ticket was
closed rapidly after your work creating the code. I can imagine it might be
a bit frustrating.
Thanks for trying to improve Django. I see you've submitted some other PR's
since, thanks for that work.
My thoughts
Hi Dan,
I think this has not got much of a response because it might be a bit niche
- it really depends where your teams are struggling to use RunSQL.
Looking for other packages at
https://djangopackages.org/grids/g/database-migration/ , nothing seems to
be related. They are all
