3 ms·

There’s nothing that stops you from using all those things in Rails migrations.

by joevandyk 8y ago

jessaustin 8y ago
There seems to be a range of opinions in these replies.
- pmontra 8y ago
  Ultimately you can write Rails migrations in SQL. That's a fact. There are two problems with that. One is that I discovered with surprise that some developers, not only in Rails projects, don't know SQL. The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day.
  - toasterlovin 8y ago
    > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day. Isn't the point of microservices to wrap the database so that other applications don't have access to it? And if you're at a stage where you're rapidly iterating on your data model, maybe start with a monolith where iteration is less costly?
  - mnm1 8y ago
    > The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. Yeah, this is the part that's the problem, not the migrations themselves. Keeping this boilerplate in sync with the db is the bane of my existence in my framework and is a completely unnecessary task. Using the ORM itself is even worse, but I digress. In apps I started from scratch, I dropped all that garbage in favor of repositories that send straight SQL to the db and all these issues dissapeared, including the slow 10x query overhead. > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Maybe it's true for Rails, but there are plenty of frameworks that work fine without ORMs, ActiveRecord, or other such nonsense. To me, such systems are a step back from straight SQL and add unnecessary overhead that only gets in the way and slows down development. Having the SQL in a file and auto-generating functions on top like HugSQL does in Clojure (https://github.com/layerware/hugsql https://github.com/layerware/hugsql) is by far the most optimized system for db access I've seen. Other languages have these types of libraries as well. Another option is query builders. It's simply false that a db access framework needs to be configured with boilerplate based on the db schema. Yes, that's the case for the idiotic ORMs, but certainly not the case for other libraries which are available in pretty much every language.

There’s nothing that stops you from using all those things in Rails migrations.

jessaustin 8y ago

There seems to be a range of opinions in these replies.

pmontra 8y ago
Ultimately you can write Rails migrations in SQL. That's a fact. There are two problems with that. One is that I discovered with surprise that some developers, not only in Rails projects, don't know SQL. The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day.
- toasterlovin 8y ago
  > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Think about a project with microservices in many different languages and it can easily become unmanageable. "We added a foreign key from here to there, everybody update their representation of the schema." Multiply for a few times per day. Isn't the point of microservices to wrap the database so that other applications don't have access to it? And if you're at a stage where you're rapidly iterating on your data model, maybe start with a monolith where iteration is less costly?
- mnm1 8y ago
  > The other is that you still have to synchronize those migrations with changes to the models of the framework (example: add belongs_to, has_many, etc.) even if ActiveRecord autodiscovers the fields of the tables. Yeah, this is the part that's the problem, not the migrations themselves. Keeping this boilerplate in sync with the db is the bane of my existence in my framework and is a completely unnecessary task. Using the ORM itself is even worse, but I digress. In apps I started from scratch, I dropped all that garbage in favor of repositories that send straight SQL to the db and all these issues dissapeared, including the slow 10x query overhead. > The latter is true even if you write the migrations in Ruby and is true also for any pair of framework / language I know. Maybe it's true for Rails, but there are plenty of frameworks that work fine without ORMs, ActiveRecord, or other such nonsense. To me, such systems are a step back from straight SQL and add unnecessary overhead that only gets in the way and slows down development. Having the SQL in a file and auto-generating functions on top like HugSQL does in Clojure (https://github.com/layerware/hugsql https://github.com/layerware/hugsql) is by far the most optimized system for db access I've seen. Other languages have these types of libraries as well. Another option is query builders. It's simply false that a db access framework needs to be configured with boilerplate based on the db schema. Yes, that's the case for the idiotic ORMs, but certainly not the case for other libraries which are available in pretty much every language.