I prefer Ecto due to the type-safeness it brings to double-check me compared to raw SQL->Language conversions, otherwise I’d prefer straight SQL. If only the language understood SQL itself. ^.^;
OvermindDL1
brightball
Potential Tradeoffs only mentions refactoring the application.
Neglects to mention danger to deployment, potential for downtime, difficulty of rolling back the changes.
Benefit: Readability of your schema.
It’s a bad practice for a web application if downtime matters.
1
peerreynders
Joe Armstrong:
- Need at least TWO computers to make a non-stop
system
- TWO computer is concurrent and distributed
It follows that you need more than one database to maintain high availability. So when it comes to database updates you take one down at a time. If database refactoring is a hurdle you are crippling yourself.
Granted choosing to change the database clearly has consequences and risks but so does choosing not to change it - and those consequences tend to be cumulative.
Years ago people thought updating systems every two weeks was good enough, now daily or more frequent updates are not uncommon.
Refactoring Databases: Evolutionary Database Design was published 12 years ago (2006-03-03).
2
brightball
There are other ways to approach the same problem even with a single instance, without risking the downtime.
- Instead of renaming a column, you create a new one with the new name.
- Allow your new code to read from the old field if the new isn’t populated.
This ensures that in the event of a rollback on your deploy both the old and new code will work with the new state of your database. This is critical for a zero-downtime deployment.
If the deploy is successful:
- Kick off a background job to populate the new field after a successful deployment.
- On next deploy, remove the old field.
If you’ve got an application with a steady amount of traffic, that is the only safe way to avoid downtime. Two databases doesn’t actually do you any good because no matter what the old and new state of your application code have to work with the new state of the database. If you want to do that at the database level with a view that’s fine too…as long as the precaution is taken. The instant you rename a column, the old state of your application code no longer functions.
If you have two databases you can change it on one…but as soon as you make that change they are no longer in sync. As soon as their states no longer line up, you’re going to run into the exact same issue if new data is getting written to the different name.
You can do it, you just have to do it more steps than just using “rename”. In the early days of a project it’s not a big deal. When a project gets larger and people begin to rely on it, it’s reckless without proper precautions.
2
natewallis
Thanks for the replies.. this took a direction I wasn’t expecting.. looks like I have some reading to do!
BTW - I have overcome my fear of commitment and started with Ecto. I think I was throwing myself off by using phx.gen.html when I should have been building my migrations and schemas from the ground up so that I understood it better.. lesson learnt.
Till next time!
5