Surviving Django, if you care about databases
This article is trying too hard to dress the author&#x27;s limited experience up as absolute truth. For example:<p>&gt; Have you got PostgreSQL in production, but you want to test with SQLite because it&#x27;s easier to set up? If so, your tests are just a tick-box exercise: you are not testing anything remotely plausible and resembling your live system.<p>This is not completely wrong but it&#x27;s just telling you that the author has never worked in an environment where it makes sense. Anyone who has knows that this approach can be used to catch a high fraction of errors locally, while not precluding a full slower CI build.<p>&gt; Even if you added some form of manual auditing to each save() method, it will not capture changes made outside Django. It wouldn&#x27;t be very secure either: Django uses a single user to access the database so if someone manages to hijack that user, they would be able to change the data in the database and alter the audit tables to hide their traces.<p>Similarly, while it is true that Django defaults using a single user for everything you can easily configure multiple connections (containing, say, an issue with your normal web code but not your management commands), you can grant access to only SELECT and INSERT on the audit log table but not UPDATE or DELETE, etc. There&#x27;s nothing with the separate approach, of course, but it&#x27;s not like it&#x27;s some great discovery that frameworks are not intended to cover every possible use-case and sometimes you want to turn them off.<p>The extended “I hacked around because understanding the migrations module seemed like more work and then I was too far in to reconsider” section has the same problem. Being surprised that the migration system triggered an update when you renamed a field is, well, exactly what it&#x27;s designed to do. That&#x27;s exactly why there is an entire section in the documentation which tells you exactly what to do in that situation and how to avoid data loss — in that case, if the problem wasn&#x27;t making foo.bar magic (which it almost always is) you&#x27;d create multiple migrations to add the new column, move (and usually convert) the data, and drop the old column. You can even run raw SQL if there&#x27;s something like an efficiency hack which makes it worthwhile. This takes a couple of minutes and is reliable.