| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| | |
Remove unused deprecation notice
|
| |
| |
| |
| |
| | |
The `rake db:test:*` tasks were deprecated in #13528, but were
undeprecated and added back in via #17739.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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
```
|
| |
|
|
|
| |
It appears that as of version 4 the `db:test:prepare` task no longer depends on the `abort_if_pending_migrations` task, which leaves this comment out of sync.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These new methods are used from the Active Record model layer to
determine which relations are viable to back a model. These new methods
allow us to change `conn.tables` in the future to only return tables and
no views. Same for `conn.table_exists?`.
The goal is to provide the following introspection methods on the
connection:
* `tables`
* `table_exists?`
* `views`
* `view_exists?`
* `data_sources` (views + tables)
* `data_source_exists?` (views + tables)
|
|\
| |
| |
| | |
Use `ActiveRecord::Tasks::DatabaseTasks.migrations_paths` explicit for db tasks
|
|/
|
|
| |
`Migrator.migrations_paths`
|
|
|
|
|
| |
Many user look `desc` of rake task and they are not familiar with `AR`.
`Active Record` is more familiar word.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`
|
|
|
|
| |
revert create and drop task descriptions
|
|
|
|
|
|
|
|
|
|
|
|
| |
db:reset should not prematurely load the environment, so, for instance,
if there is any initializer that touches th DB, it will not touch that
before droping it.
Also this makes the code simpler.
This changed was made back in 15fb4302b6ff16e641b6279a3530eb8ed97f2899
, not sure why. But I am pretty much sure we should do it like this, as
drop and setup should load its dependencies tasks if necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calebthompson/dont-rely-on-environment-task-for-schema-load"
This reverts commit 08ff4ccbbb3fb143a02e6752efb974a4bcfcd3bb, reversing
changes made to 6c9ed6dbc62450cdb87559afd15798305e069146.
Caused by #17920.
Closes #19545.
This patch introduced regressions because initializers were no longer
loaded. Specifically missing inflections result in broken restores of
the database.
|
|
|
|
|
|
|
|
|
| |
`sql_runtime` was getting invoked even when the logger was set to fatal.
This ensures that does not happen by checking that the logger is set to
info level before logging the view runtime.
This reduces the number of times `sql_runtime` is called for integration
tests with a fatal logger from 6 to 2.
|
| |
|
|
|
|
|
| |
`rake test:load_structure` already uses `SCHEMA` and there's no
need to maintain two different env vars.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the behavior :environment was giving (that db:schema:load needed)
was provided as well with :load_config.
This will address an issue introduced in
https://github.com/rails/rails/pull/15394. The fact that db:schema:load
now drops and creates the database causes the Octopus gem to have [an
issue](https://github.com/tchandy/octopus/issues/273) during the drop
step for the test database (which wasn't happening in db:schema:load
before). The error looks like:
ActiveRecord::StatementInvalid: PG::ObjectInUse: ERROR: cannot drop the currently open database
: DROP DATABASE IF EXISTS "app_test"
Because of the timing, this issue is present in master, 4-2-*, and
4.1.8.
A note to forlorn developers who might see this: "Additionally" in a
commit message means you should have a separate commit, with a separate
justification for changes. Small commits with big messages are your
friends.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
db:fixtures:load"
This reverts commit 482fdad5ef8a73688b50bba3991dd4ef6f286edd.
Fixes #17237.
|
|
|
|
|
|
| |
Hash#keys.each allocates an array of keys; Hash#each_key iterates through the
keys without allocating a new array. This is the reason why Hash#each_key
exists.
|
|
|
|
|
|
|
|
|
|
| |
The rake tasks and the `DatabaseTakss` adapter classes used to
assume a configuration at some places. This forced the rake
tasks to establish a specific connection before calling into
`load_schema`.
After #15394 this started to cause issues because it could
`purge` the wrong database before loading the schema.
|
|
|
|
|
|
| |
This extracts the logic that was embedded in a Rake task into a static
method.
Bonus: the first test for `rake db:migrate`
|
| |
|
| |
|
|
|
|
| |
ActiveRecord#pluck
|
|
|
|
| |
It allows the code to be more declarative and elegant.
|
| |
|
| |
|
|
|
|
|
| |
`ActiveRecord::FixtureSet.create_fixtures` can accept an array of
fixture_files.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Before this commit, if `ENV['FIXTURES_PATH']` was set, then `Rails.root`
was used, otherwise the app used `ActiveRecord::Tasks::DatabaseTasks.root`.
Now it is consistent.
|
| |
|
| |
|
|
|
|
|
|
|
| |
The migration numbers were normalized different ways. This left
the task output in an inconsistent state.
Closes #15538.
|
|
|
|
| |
This PR fixes #8930 and some stuff from #8985
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Add hint to error message of task db:migrate:down
|
| | |
|
|/
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently Active Record can be configured via the environment variable `DATABASE_URL` or by manually injecting a hash of values which is what Rails does, reading in `database.yml` and setting Active Record appropriately. Active Record expects to be able to use `DATABASE_URL` without the use of Rails, and we cannot rip out this functionality without deprecating. This presents a problem though when both config is set, and a `DATABASE_URL` is present. Currently the `DATABASE_URL` should "win" and none of the values in `database.yml` are used. This is somewhat unexpected to me if I were to set values such as `pool` in the `production:` group of `database.yml` they are ignored.
There are many ways that active record initiates a connection today:
- Stand Alone (without rails)
- `rake db:<tasks>`
- ActiveRecord.establish_connection
- With Rails
- `rake db:<tasks>`
- `rails <server> | <console>`
- `rails dbconsole`
We should make all of these behave exactly the same way. The best way to do this is to put all of this logic in one place so it is guaranteed to be used.
Here is my prosed matrix of how this behavior should work:
```
No database.yml
No DATABASE_URL
=> Error
```
```
database.yml present
No DATABASE_URL
=> Use database.yml configuration
```
```
No database.yml
DATABASE_URL present
=> use DATABASE_URL configuration
```
```
database.yml present
DATABASE_URL present
=> Merged into `url` sub key. If both specify `url` sub key, the `database.yml` `url`
sub key "wins". If other paramaters `adapter` or `database` are specified in YAML,
they are discarded as the `url` sub key "wins".
```
### Implementation
Current implementation uses `ActiveRecord::Base.configurations` to resolve and merge all connection information before returning. This is achieved through a utility class: `ActiveRecord::ConnectionHandling::MergeAndResolveDefaultUrlConfig`.
To understand the exact behavior of this class, it is best to review the behavior in activerecord/test/cases/connection_adapters/connection_handler_test.rb though it should match the above proposal.
|