| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fix #28905
|
|
|
|
|
| |
Raise error on the movement of migrations
when the current migration does not exist.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add stronger assertions to rake migration tasks to make sure the user is providing a numeric VERSION
An empty string was getting converted to version = 0. This would in turn pass the presence check.
Address linting warning
Add test for rake task and refactor code to meet expectations
In particular passing VERSION=0 should not raise an error.
Addressed Comments for PR #28485. Trimmed empty lines + change of wording for error message
Adjust test for change of wording in error message
Change condition to follow rails idioms
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
| |
- The `boot_rails` method from abstract_unit.rb is empty after 2abcdfd978fdcd491576a237e8c6b.
- So let's remove it and its usage.
|
|
|
|
|
|
| |
everywhere(the default behaviour now) instead of mix of /bin/rake /bin/rails everywhere
[Ryo Hashimoto & Vipul A M]
|
|
|
|
|
|
|
|
| |
Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.
Application code should *not* do this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`1_valid_people_have_last_names.rb` and
`20150823202140_create_users.rb` are valid migration file name.
But `1_valid_people_have_last_names.rb` is rendered as
`********** NO FILE **********` when `rake db:migrate:status`.
Fix to this bug, this commit includes
* define some API private methdos and a Constant
`match_to_migration_filename?`, `parse_migration_filename`, and
`MigrationFilenameRegexp`
* use these methods in `db:migrate:status` task
Example:
These files are in `db/migrate`
* 1_valid_people_have_last_names.rb
* 20150819202140_irreversible_migration.rb
* 20150823202140_add_admin_flag_to_users.rb
* 20150823202141_migration_tests.rb
* 2_we_need_reminders.rb
* 3_innocent_jointable.rb
we can migrate all of them.
Before
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 ********** NO FILE **********
up 002 ********** NO FILE **********
up 003 ********** NO FILE **********
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
After
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 Valid people have last names
up 002 We need reminders
up 003 Innocent jointable
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #20743.
The task `db:_dump` now only dumps the schema if
`ActiveRecord::Base.dump_schema_after_migration` is true. This has
effects:
- `db:migrate:up`
- `db:migrate:down`
- `db:forward`
- `db:rollback`
|
|
|
|
|
| |
We recommend using the `bin/` executables in our docs and guides.
Let's make sure that our tests execute the same code path.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Add a config on Active Record named `dump_schema_after_migration`
* Schema dump doesn't happen if the config is set to false
* Set default value of the config to true
* Set config in generated production environment file to false
* Update configuration guide
* Update CHANGELOG
|
|
|
|
|
|
|
|
| |
* Fix Migration#reversible by not using `transaction`.
* Adapt mysql adapter to updated api for remove_column
* Update test after aedcd683684d08eaf30623a4b48ce31a31426372
|
| |
|
| |
|
| |
|
|
|
|
| |
reload_classes_only_on_change schema.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Scope in migrations can be defined by adding suffix in filename,
like: 01_a_migration.blog.rb. Such migration have blog scope.
Scope is automatically added while copying migrations from engine,
so if you want to revert all of the migrations from given engine,
you can just run db:migrate with SCOPE, like:
rake db:migrate SCOPE=blog
|
|
railties/test/application/rake/migrations_test.rb
|