Rails generate schema rb file

Active Oldest Votes. But if that doesn't work, or isn't an option for some reason, you could always work around that by creating a bare bones rails app to do the schema load: Create a new rails app: rails new app -fixer Copy your gemfile unless there are specific exceptions to the fixer app. Copy your database. Copy your schema. Do all appropriate "bundle install" commands as needed for your app. Then run "rake db:drop db:create db:schema:load" That will build up a new database from scratch, based on your current schema.

Improve this answer. You can add a check for the table existance in your initializer. Cluster Cluster 5, 1 1 gold badge 24 24 silver badges 34 34 bronze badges.

I ended up using this approach in the ActiveAdmin gem's initializer, since that gem loads completely improperly. I'm not sure why this answer has less votes than other one. It's simplest and fully working. Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. If you need the power of a model, you can include a simplistic, disposable model definition in the migration itself.

While nice in principle, this is hard to enforce in practice. There are always needs and reasons to do something with which others may disagree. Rails 4. See here stackoverflow. Show 1 more comment. Andrew Marshall Andrew Marshall Could you provide some evidence this is bad idea? It's pretty much the same reason you'd never really want to delete old commits. Migrations provide a history of your database. There's really not much of a reason to, anyway. I've worked on projects with hundreds and hundreds of migrations and at one point early migrations were collapsed because there's just no way we could ever rollback that far anyway, and a few other reasons.

But it wasn't my decision. Like I said, though, for the most part there's not really any point in merging migrations deleting should never be done. Also, like Gordon says in his answer below, it is possible older migrations are corrupted because of the deferring state of the application. In almost all cases this can be avoided by minimizing the use of models in your migrations, and possibly stubbing them.

People always seem to be afraid to use SQL in migrations—but it's a migration! SQL is more durable since it doesn't depend on your application. I always thought that point of using migrations is to be able to use more convenient language than SQL and to reuse code you have written already.

I had good thought about deleting migrations and, as you should use schema:load instead of migrate and you should keep your code in VCS, there should be no harm in deleting old migrations. It just dead code that's never executed.

In a perfect world you don't want to delete migrations, but These scenarios may make resolving the differences between migrations and the database difficult to identify, and thus may warrant doing a new schema dump, removing all existing migrations, and then loading the current schema into your new first migration. Our constraint is working as intended. While schema. For example, this is what would happen to your schema file with the same exact migration AddFirstNameConstraintToUser if you were just to use schema.

If you were to onboard a new developer to work on your project, you could potentially be operating under different database regulations. Committing structure. If you were to run rails db:setup having a structure. With schema. The same can be said about a production system. We can rest assured that the structure.

Managing the concise schema. One of the biggest growing pains when migrating to structure. Say, for instance, you pull someone's branch and run the migrations specific to that branch. Your structure. You then go back to working on your own branch and generate a new migration. This can be a bit of a hassle to deal with, and there is undoubtedly a bit of a learning curve when it comes to managing these conflicts.

By using this approach, we're making a tradeoff. We have to deal with a bit of code complexity upfront that allows us to preserve our database's advanced functionality. In turn, we also have to deal with a simpler schema representation as well as not having all the power of the database at our fingertips, e. Generally speaking, there are two strategies I've used to ensure my structure. As a rule of thumb, your structure. Generally speaking, when Rails applications are small or don't need some of the more advanced features that a database offers then it's safe to use schema.

However, as an application grows in size and complexity, an accurate reflection of the database structure is of the essence.

It will allow a team to maintain the right constraints, database modules, functions and operators that otherwise wouldn't be possible.

Learning to use Rails with a well-maintained structure. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Guest author Daniele is a full-stack developer from Italy with an eye for clean, elegant code.