45eb0f3bec
Previously if there were 2 migrations in one db and 1 migration in the other db all the migrations for db one would run and then all migrations for db two would run. If a migration in one database depended on a migration in another database then it could fail. This is probably pretty rare, however in a multi-db application that's moving tables from one db to another, running them out of order could result in a migration error. In this this change we collect all the versions for each migration and the corresponding db_config so we can run them in the order they are created rather than per-db. Closes #41664 Related #41538 Co-authored-by: John Crepezzi <john.crepezzi@gmail.com> Co-authored-by: Kiril Dokh <dsounded@gmail.com> |
||
|---|---|---|
| .. | ||
| bin | ||
| exe | ||
| lib | ||
| test | ||
| .gitignore | ||
| CHANGELOG.md | ||
| MIT-LICENSE | ||
| RDOC_MAIN.rdoc | ||
| README.rdoc | ||
| Rakefile | ||
| railties.gemspec | ||
README.rdoc
= Railties -- Gluing the Engine to the Rails Railties is responsible for gluing all frameworks together. Overall, it: * handles the bootstrapping process for a Rails application; * manages the +rails+ command line interface; * and provides the Rails generators core. == Download The latest version of Railties can be installed with RubyGems: * gem install railties Source code can be downloaded as part of the Rails project on GitHub * https://github.com/rails/rails/tree/main/railties == License Railties is released under the MIT license: * https://opensource.org/licenses/MIT == Support API documentation is at * https://api.rubyonrails.org Bug reports can be filed for the Ruby on Rails project here: * https://github.com/rails/rails/issues Feature requests should be discussed on the rails-core mailing list here: * https://discuss.rubyonrails.org/c/rubyonrails-core