5 ms·

Just wait til you actually work on some production code... For the most part you don't actually want to roll back schemas as you would lose data. And iterating

Just wait til you actually work on some production code... For the most part you don't actually want to roll back schemas as you would lose data. And iterating on SQL schemas in a live app involves all kinds of tricky edge cases and backfills, knowing when to make your changes in multiple steps, being careful not to take down the whole thing because you didn't realize a certain change required a full table lock or a certain index would take so long to create, etc. As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more. It doesn't actually make things as simple as they seem at first, and you're on your own to figure out which of its niceties are actually helpful and which are dangerous to use that you need to build your own workarounds for.

deleted 8y ago
[deleted]
noir_lord 8y ago
Or you inherit a DB that’s a complete disaster scheme wise and all the nice assumptions go out the window. I’ve mostly found that migrations work best as a structure way to just run normal SQL and know a) what ran b) when. For that they are handy. I’ve even considered how to structure a stand alone migration running tool with a nice API since the good ones for each language tend to be fairly different. It annoys me that the tooling around RDBMS in 2019 is still so shit. Prime example, try to find a halfway reasonable way to debug a badly written MySQL sproc you inherited.
- adamson 8y ago
  I’ve used Flywheel (https://flywaydb.org/ https://flywaydb.org/) for this exact problem on personal projects before and been fairly happy with it. It’s intended for use in JVM-based projects, but ships with a CLI that gets you a long way.
- FrancoisBosun 8y ago
  Sqitch by David Wheeler is a great way to manage database schemas. I haven’t uses it in production, because I mostly use Rails and haven’t felt enough pain to justify the switch. https://sqitch.org https://sqitch.org
lixtra 8y ago
> As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more. This is just wrong. Rails works very well for 90% of the situations. When it stops working that’s great news: You’ve won! You’re Twitter, Facebook or the next big thing. You’ll find talent and money to replace your rails app.
- jjeaff 8y ago
  I'm having trouble understanding how one could run into a bottleneck only after you reach Facebook or Google or levels. Surely if you have performance issues when you are running on 10,000 machines, you would also have a bottleneck when you start to outgrow your single machine.
  - hopler 8y ago
    Why would you need more than a single machine to serve a request? You need multiple machines to serve many requests concurrently.
dagoat 8y ago
> For the most part you don't actually want to roll back schemas as you would lose data Can you name a framework where you roll back schema changes and don't lose data? > being careful not to take down the whole thing You still need this caution if you don't use rails > a certain change required a full table lock or a certain index would take so long to create, etc. I feel like you're just describing working with a relational database in a production setting. This isn't rails specific > Rails, it's set up to be nice and simple for a hello world example Sure. I'm also pretty sure it's used in production by some great companies whose applications/APIs are a pleasure to use - SendGrid, Github, Stripe, and last time I checked Hulu to name just a few. Just because it's not the framework of choice for the majority of companies doesn't make it incapable of being used at scale.

deleted 8y ago

[deleted]

noir_lord 8y ago

Or you inherit a DB that’s a complete disaster scheme wise and all the nice assumptions go out the window. I’ve mostly found that migrations work best as a structure way to just run normal SQL and know a) what ran b) when. For that they are handy. I’ve even considered how to structure a stand alone migration running tool with a nice API since the good ones for each language tend to be fairly different. It annoys me that the tooling around RDBMS in 2019 is still so shit. Prime example, try to find a halfway reasonable way to debug a badly written MySQL sproc you inherited.

adamson 8y ago
I’ve used Flywheel (https://flywaydb.org/ https://flywaydb.org/) for this exact problem on personal projects before and been fairly happy with it. It’s intended for use in JVM-based projects, but ships with a CLI that gets you a long way.
FrancoisBosun 8y ago
Sqitch by David Wheeler is a great way to manage database schemas. I haven’t uses it in production, because I mostly use Rails and haven’t felt enough pain to justify the switch. https://sqitch.org https://sqitch.org

lixtra 8y ago

> As is so often the case in Rails, it's set up to be nice and simple for a hello world example but little more. This is just wrong. Rails works very well for 90% of the situations. When it stops working that’s great news: You’ve won! You’re Twitter, Facebook or the next big thing. You’ll find talent and money to replace your rails app.

jjeaff 8y ago
I'm having trouble understanding how one could run into a bottleneck only after you reach Facebook or Google or levels. Surely if you have performance issues when you are running on 10,000 machines, you would also have a bottleneck when you start to outgrow your single machine.
- hopler 8y ago
  Why would you need more than a single machine to serve a request? You need multiple machines to serve many requests concurrently.

dagoat 8y ago

> For the most part you don't actually want to roll back schemas as you would lose data Can you name a framework where you roll back schema changes and don't lose data? > being careful not to take down the whole thing You still need this caution if you don't use rails > a certain change required a full table lock or a certain index would take so long to create, etc. I feel like you're just describing working with a relational database in a production setting. This isn't rails specific > Rails, it's set up to be nice and simple for a hello world example Sure. I'm also pretty sure it's used in production by some great companies whose applications/APIs are a pleasure to use - SendGrid, Github, Stripe, and last time I checked Hulu to name just a few. Just because it's not the framework of choice for the majority of companies doesn't make it incapable of being used at scale.