New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bring back `db:test:prepare`. #17739

Merged
merged 2 commits into from Nov 25, 2014

Conversation

Projects
None yet
6 participants
@senny
Member

senny commented Nov 24, 2014

Closes #17171
Closes #15787

This reverts deprecations added in #13528.
The task is brought back for two reasons:

  1. Give plugins a way to hook into the test database initialization process
  2. Give the user a way to force a test database synchronization

While test:prepare is still a dependency of every test task, db:test:prepare
no longer hooks into it. This means that test:prepare runs before the schema
is synchronized. Plugins, which insert data can now hook into db:test:prepare.

The automatic schema maintenance can't detect when a migration is rolled-back,
modified and reapplied. In this case the user has to fall back to db:test:prepare
to force the synchronization to happen.

Context

Since automatic schema maintenance has been shipped with 4.1 we need a backportable solution. This patch tries to address parts of the problems reported in #17171, #17170, #15787

We started to move away from rake as the primary mechanism to setup the testing environment. Some parts (like existing hooks) did not get the necessary attention. For 5.0 we can finish that transition and provide a sensible upgrade path for plugins.

Discussion

This patch brings the following shortcomings:

  • It doesn't restore the hooks as they were. test:prepare still runs before the schema was maintained. Plugins that rely on the schema need to switch to the db:test:prepare hook.
  • maintain_test_schema! now shells out to bin/rake to synchronize the schema. This adds the cost of loading the Rails environment twice when changes are detected.
  • We already started issuing deprecations in 4.1. this might come as an unexpected change.

TODO

  • Write tests
  • Adjust documentation
  • Add CHANGELOG entry
@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Nov 24, 2014

Member

This idea came up in a discussion with @dhh. It's not a complete solution but should be backportable. Goal is to solve the immediate problems so we have time to rework it for 5.0.

@matthewd @metaskills @rafaelfranca Eager to hear your thoughts.

/cc @chancancode

Member

senny commented Nov 24, 2014

This idea came up in a discussion with @dhh. It's not a complete solution but should be backportable. Goal is to solve the immediate problems so we have time to rework it for 5.0.

@matthewd @metaskills @rafaelfranca Eager to hear your thoughts.

/cc @chancancode

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Nov 24, 2014

Member

@jeremy Would this be sufficient to get your plugin hook working when you hook into both test:prepare and db:test:prepare ?

Member

senny commented Nov 24, 2014

@jeremy Would this be sufficient to get your plugin hook working when you hook into both test:prepare and db:test:prepare ?

@senny senny added the activerecord label Nov 24, 2014

@chancancode chancancode added this to the 4.2.0 milestone Nov 24, 2014

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Nov 25, 2014

Member

Seems good to me

Member

rafaelfranca commented Nov 25, 2014

Seems good to me

@metaskills

This comment has been minimized.

Show comment
Hide comment
@metaskills

metaskills Nov 25, 2014

Contributor

@senny Thanks for the great write up.

I have advocated for years now that people use test:prepare vs the lower level db:test:prepare so gems like rspec (see this issue) can stay agnostic on test setup. Pushing db:test:prepare as an interface assumes Rails has an ORM setup and feels like a step backward.

Perhaps this 4.2.x jankiness has no option? Will Rails 5.0 still carry the improper db:test:prepare as the interface too?

Contributor

metaskills commented Nov 25, 2014

@senny Thanks for the great write up.

I have advocated for years now that people use test:prepare vs the lower level db:test:prepare so gems like rspec (see this issue) can stay agnostic on test setup. Pushing db:test:prepare as an interface assumes Rails has an ORM setup and feels like a step backward.

Perhaps this 4.2.x jankiness has no option? Will Rails 5.0 still carry the improper db:test:prepare as the interface too?

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Nov 25, 2014

Member

@metaskills Thanks for your reply. This patch tries to bring back the hook in a backportable manner. For 5.0 I'd like to finish the transition we started in 4.1 to move away from rake as means to setup the test environment. However we need to provide the same functionality for plugins to hook into the cycle and make necessary modifications.

Brining back db:test:prepare also allows to fall back to the old way of schema maintenance by setting ActiveRecord::Base.maintain_test_schema = false and maybe even adding db:test:prepare as dependency to test:prepare.

@metaskills does this work for you?

Member

senny commented Nov 25, 2014

@metaskills Thanks for your reply. This patch tries to bring back the hook in a backportable manner. For 5.0 I'd like to finish the transition we started in 4.1 to move away from rake as means to setup the test environment. However we need to provide the same functionality for plugins to hook into the cycle and make necessary modifications.

Brining back db:test:prepare also allows to fall back to the old way of schema maintenance by setting ActiveRecord::Base.maintain_test_schema = false and maybe even adding db:test:prepare as dependency to test:prepare.

@metaskills does this work for you?

@senny

View changes

Show outdated Hide outdated activerecord/lib/active_record/railtie.rb Outdated
@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Nov 25, 2014

Member

I pushed a new version. The use-cases we solve are now added as tests. They serve as a reminder when we move forward.

This patch can't be merged as there is an issue with the initializer order: #17739 (comment)

@chancancode Do you think we need to document this in other places than the CHANGELOG?

Member

senny commented Nov 25, 2014

I pushed a new version. The use-cases we solve are now added as tests. They serve as a reminder when we move forward.

This patch can't be merged as there is an issue with the initializer order: #17739 (comment)

@chancancode Do you think we need to document this in other places than the CHANGELOG?

senny added some commits Nov 25, 2014

do not trigger AR lazy load hook before initializers ran.
[Rafael Mendonça França & Yves Senn]

This require caused the `active_record.set_configs` initializer to
run immediately, before `config/initializers`. This means that setting any
configuration on `Rails.application.config.active_record` inside of
an initializer had no effects when rails was loaded through `rake`.

Introduced by #6518

/cc @rafaelfranca
bring back `db:test:prepare`.
This reverts deprecations added in #13528.
The task is brought back for two reasons:
  1. Give plugins a way to hook into the test database initialization process
  2. Give the user a way to force a test database synchronization

While `test:prepare` is still a dependency of every test task, `db:test:prepare`
no longer hooks into it. This means that `test:prepare` runs before the schema
is synchronized. Plugins, which insert data can now hook into `db:test:prepare`.

The automatic schema maintenance can't detect when a migration is rolled-back,
modified and reapplied. In this case the user has to fall back to `db:test:prepare`
to force the synchronization to happen.
@@ -36,8 +36,6 @@ class Railtie < Rails::Railtie # :nodoc:
config.eager_load_namespaces << ActiveRecord
rake_tasks do
require "active_record/base"

This comment has been minimized.

@rafaelfranca
@rafaelfranca

rafaelfranca Nov 25, 2014

Member

👍

senny added a commit that referenced this pull request Nov 25, 2014

@senny senny merged commit 208908f into master Nov 25, 2014

1 check failed

continuous-integration/travis-ci The Travis CI build could not complete due to an error
Details

@senny senny deleted the bring_back_db_test_prepare branch Nov 25, 2014

@metaskills

This comment has been minimized.

Show comment
Hide comment
@metaskills

metaskills Nov 27, 2014

Contributor

I am looking over this now, I think there may be some issues.

Contributor

metaskills commented Nov 27, 2014

I am looking over this now, I think there may be some issues.

@metaskills

This comment has been minimized.

Show comment
Hide comment
@metaskills

metaskills Nov 27, 2014

Contributor

OK, no issues. For some reason I had to use Rake's #enhance vs the short hand syntax. So this did not work:

task 'db:test:prepare' => 'named_seeds:prepare'

But this did:

Rake::Task['db:test:prepare'].enhance { Rake::Task['named_seeds:prepare'].invoke }
Contributor

metaskills commented Nov 27, 2014

OK, no issues. For some reason I had to use Rake's #enhance vs the short hand syntax. So this did not work:

task 'db:test:prepare' => 'named_seeds:prepare'

But this did:

Rake::Task['db:test:prepare'].enhance { Rake::Task['named_seeds:prepare'].invoke }
@metaskills

This comment has been minimized.

Show comment
Hide comment
@metaskills
Contributor

metaskills commented Nov 27, 2014

@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Nov 28, 2014

Member

Comment updated (6c83d4b)

@metaskills using task 'db:test:prepare' => 'named_seeds:prepare' doesn't work as it adds named_seeds:prepare as a dependency to db:test:prepare. This means that it runs before the task itself and therefore before the schema is loaded.

This used to work with test:prepare as db:test:prepare was added as a dependency by Active Record as well. This way you could add more dependencies to that task, which would run after the schema has been loaded.

The PR includes a test to showcase the enhance behavior: https://github.com/rails/rails/blob/master/railties/test/application/test_test.rb#L246-L260

Member

senny commented Nov 28, 2014

Comment updated (6c83d4b)

@metaskills using task 'db:test:prepare' => 'named_seeds:prepare' doesn't work as it adds named_seeds:prepare as a dependency to db:test:prepare. This means that it runs before the task itself and therefore before the schema is loaded.

This used to work with test:prepare as db:test:prepare was added as a dependency by Active Record as well. This way you could add more dependencies to that task, which would run after the schema has been loaded.

The PR includes a test to showcase the enhance behavior: https://github.com/rails/rails/blob/master/railties/test/application/test_test.rb#L246-L260

@metaskills

This comment has been minimized.

Show comment
Hide comment
@metaskills

metaskills Nov 28, 2014

Contributor

using task 'db:test:prepare' => 'named_seeds:prepare' doesn't work

Thanks, I realized that shortly after I posted 👍

This used to work with test:prepare as db:test:prepare was added as a dependency by Active Record as well.

Ah, that makes total sense now. Huge thanks for pointing that out.

Contributor

metaskills commented Nov 28, 2014

using task 'db:test:prepare' => 'named_seeds:prepare' doesn't work

Thanks, I realized that shortly after I posted 👍

This used to work with test:prepare as db:test:prepare was added as a dependency by Active Record as well.

Ah, that makes total sense now. Huge thanks for pointing that out.

@Eric-Guo

This comment has been minimized.

Show comment
Hide comment
@Eric-Guo

Eric-Guo Nov 29, 2014

Contributor

But the problem is it will break rsim/oracle-enhanced#523, so maybe still need?

Contributor

Eric-Guo commented on 9e9793b Nov 29, 2014

But the problem is it will break rsim/oracle-enhanced#523, so maybe still need?

This comment has been minimized.

Show comment
Hide comment
@senny

senny Dec 3, 2014

Member

@Eric-Guo I'd rather not revert this. Can the issue be solved from the oracle adapter gem? /cc @yahonda

Member

senny replied Dec 3, 2014

@Eric-Guo I'd rather not revert this. Can the issue be solved from the oracle adapter gem? /cc @yahonda

This comment has been minimized.

Show comment
Hide comment
@yahonda

yahonda Dec 3, 2014

Contributor

rsim/oracle-enhanced#526 should fix rsim/oracle-enhanced#523. Thanks for the info.

Contributor

yahonda replied Dec 3, 2014

rsim/oracle-enhanced#526 should fix rsim/oracle-enhanced#523. Thanks for the info.

This comment has been minimized.

Show comment
Hide comment
@senny

senny Dec 3, 2014

Member

@yahonda thank you ❤️ while this leaves oracle user open to the same issue I much prefer to have this outside of Rails and in oracle-enhanced 👍

Member

senny replied Dec 3, 2014

@yahonda thank you ❤️ while this leaves oracle user open to the same issue I much prefer to have this outside of Rails and in oracle-enhanced 👍

This comment has been minimized.

Show comment
Hide comment
@yahonda

yahonda Dec 3, 2014

Contributor

@senny Yeah I think it has high priority to run rake -T than ignoring Rails.application.config.active_record. I have not found the better solution to solve both issues, though.

Contributor

yahonda replied Dec 3, 2014

@senny Yeah I think it has high priority to run rake -T than ignoring Rails.application.config.active_record. I have not found the better solution to solve both issues, though.

senny added a commit that referenced this pull request Dec 10, 2014

Merge pull request #17739 from rails/bring_back_db_test_prepare
bring back `db:test:prepare`.
Conflicts:
	activerecord/CHANGELOG.md
	activerecord/lib/active_record/migration.rb

This also includes the initializer-order-fix for Active Record
configurations. This patch breaks oracle-enahnced-adapter.

/cc @rafaelfranca @yahonda
@senny

This comment has been minimized.

Show comment
Hide comment
@senny

senny Dec 10, 2014

Member

I've backported this to 4-1-stable.

Member

senny commented Dec 10, 2014

I've backported this to 4-1-stable.

senny added a commit that referenced this pull request Dec 22, 2014

senny added a commit that referenced this pull request Dec 22, 2014

sivagollapalli added a commit to sivagollapalli/rails that referenced this pull request Dec 29, 2014

geoffharcourt added a commit to thoughtbot/dotfiles that referenced this pull request Nov 29, 2015

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in #260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

maclover7 added a commit to maclover7/rails that referenced this pull request Dec 5, 2015

Remove unused deprecation notice
The `rake db:test:*` tasks were deprecated in rails#13528, but were
undeprecated and added back in via rails#17739.

aauren added a commit to aauren/dotfiles that referenced this pull request Dec 21, 2015

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

bmorrall pushed a commit to bmorrall/dotfiles that referenced this pull request Jan 26, 2016

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

bmorrall pushed a commit to bmorrall/dotfiles that referenced this pull request Jan 27, 2016

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

bmorrall added a commit to bmorrall/dotfiles that referenced this pull request Jan 27, 2016

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

aauren added a commit to aauren/dotfiles that referenced this pull request Jun 11, 2016

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

echopi pushed a commit to echopi/dotfiles that referenced this pull request Nov 8, 2016

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

aliceyoung9 added a commit to aliceyoung9/dotfiles that referenced this pull request Dec 1, 2016

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

moofish32 pushed a commit to moofish32/dotfiles that referenced this pull request Jan 12, 2017

Run `db:test:prepare` task on `migrate` alias
We removed `db:test:prepare` from the `migrate` alias in thoughtbot#260 because
Rails 4.1 discouraged users from running the deprecated (at the time)
Rake task. Rails brought back `db:test:load` in rails/rails#17739 due to
user complaints about being unable to force a test database
synchronization.

Without dropping and recreating the test database from scratch, the
current migration strategy of solely using `db:migrate` and
`db:rollback` will never bring changes into test from a migration that
was run, rolled back, modified, and then re-run.

Running `db:test:load` or `db:test:prepare` on each migrate operation
has a small performance penalty, but the task is only being run when you
have a reason to want to check or force a synchronization of the
database. Knowing for sure that your test and development databases are
at the same point in their evolution is worthwhile.

Running `db:test:prepare` or `db:test:load` after running our existing
migrate alias added just under 1.0 seconds on average to the migrate
operation on an application with a reasonably sized DB schema.

diff --git a/aliases b/aliases index 6a0f602..102caca 100644 ---
a/aliases +++ b/aliases @@ -9,7 +9,7 @@ alias v="$VISUAL" alias
b="bundle"

 # Rails
-alias migrate="rake db:migrate db:rollback && rake db:migrate"
+alias migrate="rake db:migrate db:rollback && rake db:migrate db:test:prepare"
 alias s="rspec"

 # Pretty print the path

alyssais added a commit to alyssais/guard-migrate that referenced this pull request Feb 19, 2017

Replace test_clone option with test_prepare
db:test:clone is deprecated because Rails is now supposed to handle that
automatically.

However, it doesn't handle redos, because it just compares schema and
migration timestamps. db:test:prepare, however, does handle this case,
is (no longer) deprecated, and is explicitly present in Rails for this
use-case: rails/rails#17739.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment