Automatically maintain test database schema#13528
Conversation
|
Great work. If we are going to allow people to manually opt-out of this behaviour we should probably not remove db:test:prepare for the users that would prefer to do it manually. Or would they rather call |
|
@josevalim I'm basically proposing we deprecate these: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/railties/databases.rake#L301-L364 I don't see what purpose they serve any more. People who want to do these things manually can do stuff like So I don't think we need these test-specific rake tasks at all? |
|
Sounds good! |
|
@josevalim I consider this finished now, let me know if you have any more comments |
|
Seems good to me |
* Move check from generated helper to test_help.rb, so that all applications can benefit * Rather than just raising when the test schema has pending migrations, try to load in the schema and only raise if there are pending migrations afterwards * Opt out of the check by setting config.active_record.maintain_test_schema = false * Deprecate db:test:* tasks. The test helper is now fully responsible for maintaining the test schema, so we don't need rake tasks for this. This is also a speed improvement since we're no longer reloading the test database on every call to "rake test".
Automatically maintain test database schema
|
cc @alindeman in case you want to add this to rspec-rails |
|
❤️ great work here. |
|
Great job! |
|
👍 |
|
this makes me weep with joy |
|
Should rspec users add |
- [release notes][1] - [release announcement][2] - [deprecation of db:test:* tasks][3] - Had to update `sass-rails` to 4.0.2 because of an [issue with sprockets 2.12][4] [1]: http://edgeguides.rubyonrails.org/4_1_release_notes.html [2]: http://weblog.rubyonrails.org/2014/3/25/Rails-4-1-rc2/ [3]: rails/rails#13528 [4]: sstephenson/sprockets#540
|
@jaredbeck yep could do, but I think ideally the |
|
@jaredbeck I found adding |
If I'm understanding rspec/rspec-rails#946 correctly, newly-generated |
|
The only problem with removing the test load tasks, is that they purge the db before loading it, so now deleted tables will never be removed from the test db. A separate issue is we are constantly branching and merging our app, so using the latest schema info to determine if we need to load the schema does not work for us. I may be switching to a branch that has a later migration than the one I just came from, but it won't load because the test db has a more recent migration. I'm solving the problem by comparing the structure.sql mtime to the test.log mtime. Here is the patch file I created for our use. I don't think this is a global solution, but it works for us and may give you ideas if you agree that using the schema_migrations table is limited. The path file also includes patches for parallel_test, which adds additional issues: |
|
How to remove the WARNING? Do not use |
|
Yes. it should not be used anymore. |
|
Thank you @rafaelfranca. |
|
Thx for deprecating |
|
If I create a migration and migrate it: And then roll it back because I want to add or change something in the migration (say change the name of the Then the test database doesn't seem to catch the change. To alleviate this, I have to: This is more work than just copying the schema over with something like |
There was a problem hiding this comment.
seems like a ActiveRecord::Tasks::DatabaseTasks.purge is missing here. /cc @jonleighton. See #15787 Is what we were doing under test namespace
|
Any suggestions on how to hook into this behavior? I've read through it a few times looking for a good integration point but haven't found anywhere... looking to reseed when the test database is rebuilt, as we have seed data that's required for tests to pass |
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.
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.
|
I'm wondering on the status of this? I'm looking for a way to maintain a test rails env that isn't called 'test' |
We can't exec start_test_backend from inside script/ as this clashes with rails/rails#13528 somehow.
We can't exec start_test_backend from inside script/ as this clashes with rails/rails#13528 somehow.
applications can benefit
try to load in the schema and only raise if there are pending
migrations afterwards
TODO: