1. You want to start discarding migrations (because you have too many) 2. You had an existing database
Are those never a "trigger" on Django side? I appreciate the opportunity to learn!
1. You want to start discarding migrations (because you have too many) 2. You had an existing database
Are those never a "trigger" on Django side? I appreciate the opportunity to learn!
For an existing database, you can easily create django models for each table, etc. There's a --fake option to update the migration table to make it think you've applied these migrations, but not actually apply them. This convinces django you've brought the database in sync. May your deity or deities help you if you did not actually bring it in sync. I've used this quite a bit in some java ee->python migrations I've done in the past.
I do also want to add that Django can kind of do the reverse of auto-generating migrations: it can “inspect” an existing database and generate Python classes that allow you to use the Django API as if you wrote those classes yourself: https://docs.djangoproject.com/en/4.1/howto/legacy-databases...
Of course, the feature is not going to be perfect, especially if a team has been using odd naming conventions in the legacy database, but it seems helpful at least in theory.