Well, the standard schema.rb file for Rails 2 has this at the end of the comment block at the top of the file:
The Rails 3 schema.rb , which I kick, says the same thing. I think the comment says it all.
Update in response to comments: Yes, errors can be made, and you can get conflicting changes and errors that distort your schema.rb , but that is why you want it to be under version control, version control allows you to track everything and, if necessary make backups. There is only one thing in the entire source tree that indicates your database schema, which is schema.rb . Your database schema is absolutely a critical artifact, and all that matters is to be monitored in version control.
Any issues with updating / merging with schema.rb should be sorted simply by sorting your conflicting migrations, so schema.rb will be fixed as a side effect to fix the real problem.
Yes, schema.rb is a generated file, but it is generated only in the sense that your text editor generates your pancakes.rb model file or an unedited archive file is created.
Yes, you can restore your schema.rb file by creating a new database and then doing all your migrations. But you should clean your old migrations from time to time to avoid having to check hundreds of migration files every time you rake db:migrate , so "rebuild and run all migrations" is often not an option in a very active project.
mu is too short Jun 23 2018-11-11T00: 00Z
source share