in blog | Screaming At My Screen |
---|---|
original entry | Thoughts on „Surviving Django“ |
Daniele, the author of psycopg2, wrote an interesting post about Django and its migration system. Having used Django for well over a decade and having worked on projects either handed to me or greenfield at different scales I cannot agree with his arguments as they are stated.
The migration and ORM system does solve a far larger problem than allowing web apps to switch between databases. Djangos migration system is primarily a developer tool. A rather excellent one I cannot praise enough. It abstracts and standardises the way database migrations are handled. Remember following a document outlining the order of 15 migrations to apply when doing a deploy? Remember trying to add a 16th? I surely prefer running makemigrations
. Is it perfect? No. Can a talented DBA get far more out of a database? Absolutely. Is any of that more relevant than safeguards and ease of use for 90% of the apps out there? Definitely not.
Now to the really good part - you can have the best of both worlds! Migrations can run Python and SQL, while still giving you some of the safeguards and making it comfortable to use. They will not get in your way, but spare you from writing your own tooling around migrations or using yet another tool.
Django is a great framework if you use it as it is. Once you start replacing parts you will end up fighting the framework on a regular basis or start re-implementing most of the third party libraries which expect Django to work the way Django does. If you end up at this point you would likely have a better time with Flask and one or two blueprints.