> This article is trying too hard to dress the author's limited experience up as absolute truth.
Sure you're not doing the same thing? As Vivekseth writes below, the author wrote psycopg2.
---
Allowing the DB user that the web app uses to have schema modification privileges is a massive security hole. If you're not hacked, someone will eventually drop the production database.
So, migrations in anything but SQL are a Bad Idea.
Yes, you’ll notice that I’m not saying his ideas have no place but that they’re not universally applicable. For example, the security “hole” is trivially avoidable by using a different settings file to do migrations on a separate server/container which doesn’t get normal web traffic.
If you want SQL, you can also generate it from your migrations and send it over to someone else to run. This is not uncommon in enterprise IT.
Limited does not mean he hasn’t accomplished anything, only that he’s not speaking for the entire community and wording his post that way doesn’t add anything to it.
He’s obviously very proficient, which is going to shape your perspective of what’s easy and how much control you want just like the scale of the projects you work on and the number and skill levels of your team.
There’s nothing wrong with his opinion - my objection is the overly broad framing. It would have been just as good as “here are some things which worked for us” and letting the reader decide whether they are in the same situation.
Sure you're not doing the same thing? As Vivekseth writes below, the author wrote psycopg2.
--- Allowing the DB user that the web app uses to have schema modification privileges is a massive security hole. If you're not hacked, someone will eventually drop the production database.
So, migrations in anything but SQL are a Bad Idea.