| My experience from running a django app with thousands of migrations and dozen of apps - Testing involving models is slow. It runs all your migration. Python's own "Unittest" is fast for functions not involving models. - The suggested pattern for business logic is "active record", which is putting functions about a model alongside the model itself. Good for clean case. Doesn't really work when your operation involve multiple models. - But if you put function about a model inside a model, the migration doesn't serialize the function into migration history (I could be wrong) - "Data" migration is handy when you want enum-like data in database available to all teammates. e.g. list of currencies - It is very tempting for new team member just to create an django app, with its own view and model, because it feels like starting a fresh without needing to care about existing business context. On the other hand, designing conceptual boundary between apps is very important. Because starting app is easy, and often (not always) wrong. - The squash migration utils are limited because I guess of relatively low usage. It squashes linear migration history (with manual curation of starting and ending migration node I think? Not sure about latest state). I wrote a util to squash whole migration history by finding linear segments and squash those segment of history one by one. Didn't release it, but wrote some notes https://gist.github.com/kmcheung12/08b4c234b38c23efd43550da9... |