aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/railties/databases.rake
Commit message (Collapse)AuthorAgeFilesLines
* Convert configs_for to kwargs, add include_replicasEileen Uchitelle2018-08-311-9/+9
| | | | | | | | | | | Changes the `configs_for` method from using traditional arguments to using kwargs. This is so I can add the `include_replicas` kwarg without having to always include `env_name` and `spec_name` in the method call. `include_replicas` defaults to false because everywhere internally in Rails we don't want replicas. `configs_for` is for iterating over configurations to create / run rake tasks, so we really don't ever need replicas in that case.
* Refactors Active Record connection managementEileen Uchitelle2018-08-301-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While the three-tier config makes it easier to define databases for multiple database applications, it quickly became clear to offer full support for multiple databases we need to change the way the connections hash was handled. A three-tier config means that when Rails needed to choose a default configuration (in the case a user doesn't ask for a specific configuration) it wasn't clear to Rails which the default was. I [bandaid fixed this so the rake tasks could work](#32271) but that fix wasn't correct because it actually doubled up the configuration hashes. Instead of attemping to manipulate the hashes @tenderlove and I decided that it made more sense if we converted the hashes to objects so we can easily ask those object questions. In a three tier config like this: ``` development: primary: database: "my_primary_db" animals: database; "my_animals_db" ``` We end up with an object like this: ``` @configurations=[ #<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10 @env_name="development",@spec_name="primary", @config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>, #<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90 @env_name="development",@spec_name="animals", @config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}> ]> ``` The configurations setter takes the database configuration set by your application and turns them into an `ActiveRecord::DatabaseConfigurations` object that has one getter - `@configurations` which is an array of all the database objects. The configurations getter returns this object by default since it acts like a hash in most of the cases we need. For example if you need to access the default `development` database we can simply request it as we did before: ``` ActiveRecord::Base.configurations["development"] ``` This will return primary development database configuration hash: ``` { "database" => "my_primary_db" } ``` Internally all of Active Record has been converted to use the new objects. I've built this to be backwards compatible but allow for accessing the hash if needed for a deprecation period. To get the original hash instead of the object you can either add `to_h` on the configurations call or pass `legacy: true` to `configurations. ``` ActiveRecord::Base.configurations.to_h => { "development => { "database" => "my_primary_db" } } ActiveRecord::Base.configurations(legacy: true) => { "development => { "database" => "my_primary_db" } } ``` The new configurations object allows us to iterate over the Active Record configurations without losing the known environment or specification name for that configuration. You can also select all the configs for an env or env and spec. With this we can always ask any object what environment it belongs to: ``` db_configs = ActiveRecord::Base.configurations.configurations_for("development") => #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800 @configurations=[ #<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10 @env_name="development",@spec_name="primary", @config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>, #<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90 @env_name="development",@spec_name="animals", @config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}> ]> db_config.env_name => "development" db_config.spec_name => "primary" db_config.config => { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" } ``` The configurations object is more flexible than the configurations hash and will allow us to build on top of the connection management in order to add support for primary/replica connections, sharding, and constructing queries for associations that live in multiple databases.
* Add missing load config dependency to `rake db:seed`Tobias Bielohlawek2018-07-101-1/+1
|
* Fix structure:dump for multiple databaseseileencodes2018-04-061-2/+1
| | | | | | | | ccea4cf broke multiple database structure:dump, the current_config line should have been deleted instead. I'm struggling to write a test for this since the confings are passed from rake to the structure_dump method rather than the other way around. Hoping to come up with a test while I work on structure:load commands for multiple databases.
* Use current_config in structure_dumputilum2018-03-291-1/+1
| | | | This looks like a typo from 0f0aa6a275876502e002c054896734d6536ba5cd
* Refactor configs_for and friendseileencodes2018-03-211-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Moves the configs_for and DatabaseConfig struct into it's own file. I was considering doing this in a future refactoring but our set up forced me to move it now. You see there are `mattr_accessor`'s on the Core module that have default settings. For example the `schema_format` defaults to Ruby. So if I call `configs_for` or any methods in the Core module it will reset the `schema_format` to `:ruby`. By moving it to it's own class we can keep the logic contained and avoid this unfortunate issue. The second change here does a double loop over the yaml files. Bear with me... Our tests dictate that we need to load an environment before our rake tasks because we could have something in an environment that the database.yml depends on. There are side-effects to this and I think there's a deeper bug that needs to be fixed but that's for another issue. The gist of the problem is when I was creating the dynamic rake tasks if the yaml that that rake task is calling evaluates code (like erb) that calls the environment configs the code will blow up because the environment is not loaded yet. To avoid this issue we added a new method that simply loads the yaml and does not evaluate the erb or anything in it. We then use that yaml to create the task name. Inside the task name we can then call `load_config` and load the real config to actually call the code internal to the task. I admit, this is gross, but refactoring can't all be pretty all the time and I'm working hard with `@tenderlove` to refactor much more of this code to get to a better place re connection management and rake tasks.
* Update schema/structure dump tasks for multi dbeileencodes2018-03-211-12/+20
| | | | | | | Adds the ability to dump the schema or structure files for mulitple databases. Loops through the configs for a given env and sets a filename based on the format, then establishes a connection for that config and dumps into the file.
* Add ability to create/drop/migrate all dbs for a given enveileencodes2018-03-211-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `each_current_configuration` is used by create, drop, and other methods to find the configs for a given environment and returning those to the method calling them. The change here allows for the database commands to operate on all the configs in the environment. Previously we couldn't slice the hashes and iterate over them becasue they could be two tier or could be three tier. By using the database config structs we don't need to care whether we're dealing with a three tier or two tier, we can just parse all the configs based on the environment. This makes it possible for us to run `bin/rails db:create` and it will create all the configs for the dev and test environment ust like it does for a two tier - it creates the db for dev and test. Now `db:create` will create `primary` for dev and test, and `animals` for dev and test if our database.yml looks like: ``` development: primary: etc animals: etc test: primary: etc animals: etc ``` This means that `bin/rails db:create`, `bin/rails db:drop`, and `bin/rails db:migrate` will operate on the dev and test env for both primary and animals ds.
* Add create/drop/migrate db tasks for each database in the environmenteileencodes2018-03-211-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a three-tier yaml file like this: ``` development: primary: database: "development" animals: database: "development_animals" migrations_paths: "db/animals_migrate" ``` This will add db create/drop/and migrate tasks for each level of the config under that environment. ``` bin/rails db:drop:primary bin/rails db:drop:animals bin/rails db:create:primary bin/rails db:create:animals bin/rails db:migrate:primary bin/rails db:migrate:animals ```
* Call `YAML.load` correctlyeileencodes2018-02-211-1/+1
| | | | | We should call methods with `.method_name` not `::method_name`. Fix two instances of `YAML::load` I found in favor of `YAML.load`.
* Refactor migration to move migrations paths to connectioneileencodes2018-01-181-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rails has some support for multiple databases but it can be hard to handle migrations with those. The easiest way to implement multiple databases is to contain migrations into their own folder ("db/migrate" for the primary db and "db/seconddb_migrate" for the second db). Without this you would need to write code that allowed you to switch connections in migrations. I can tell you from experience that is not a fun way to implement multiple databases. This refactoring is a pre-requisite for implementing other features related to parallel testing and improved handling for multiple databases. The refactoring here moves the class methods from the `Migrator` class into it's own new class `MigrationContext`. The goal was to move the `migrations_paths` method off of the `Migrator` class and onto the connection. This allows users to do the following in their `database.yml`: ``` development: adapter: mysql2 username: root password: development_seconddb: adapter: mysql2 username: root password: migrations_paths: "db/second_db_migrate" ``` Migrations for the `seconddb` can now be store in the `db/second_db_migrate` directory. Migrations for the primary database are stored in `db/migrate`". The refactoring here drastically reduces the internal API for migrations since we don't need to pass `migrations_paths` around to every single method. Additionally this change does not require any Rails applications to make changes unless they want to use the new public API. All of the class methods from the `Migrator` class were `nodoc`'d except for the `migrations_paths` and `migrations_path` getter/setters respectively.
* Add `environment` as dependency of `load_config` (#31135)Yuji Yaginuma2017-11-141-24/+24
| | | | | | | | | | | | Currently the environment is not loaded in some db tasks. Therefore, if use encrypted secrets values in `database.yml`, `read_encrypted_secrets` will not be true, so the value can not be used correctly. To fix this, added `environment` as dependency of `load_config`. It also removes explicit `environment` dependencies that are no longer needed. Fixes #30717
* Fix `bin/rails db:migrate` with specified `VERSION`bogdanvlviv2017-11-061-4/+15
| | | | | | Ensure that `bin/rails db:migrate` with specified `VERSION` reverts all migrations only if `VERSION` is `0`. Raise error if target migration doesn't exist.
* [Active Record] require => require_relativeAkira Matsuda2017-10-211-3/+3
| | | | This basically reverts 9d4f79d3d394edb74fa2192e5d9ad7b09ce50c6d
* Fix `bin/rails db:setup` and `bin/rails db:test:prepare` create wrong ↵bogdanvlviv2017-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | ar_internal_metadata's data for a test database. Before: ``` $ RAILS_ENV=test rails dbconsole > SELECT * FROM ar_internal_metadata; key|value|created_at|updated_at environment|development|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679 ``` After: ``` $ RAILS_ENV=test rails dbconsole > SELECT * FROM ar_internal_metadata; key|value|created_at|updated_at environment|test|2017-09-11 23:14:10.815679|2017-09-11 23:14:10.815679 ``` Fixes #26731.
* Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
|
* [Active Record] require => require_relativeAkira Matsuda2017-07-011-3/+3
|
* Also raise error when VERSION is nilRafael Mendonça França2017-04-271-2/+2
| | | | Fix #28905
* Fixes #28359Philippe Guay2017-03-261-2/+5
| | | | | | | | | | | | | | | | 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
* Fix `rake db:migrate:status` with subdirectoriesRyuta Kamizono2017-03-041-17/+2
| | | | | | | | | | | | `db:migrate` supports subdirectories and have a test. https://github.com/rails/rails/blob/v5.1.0.beta1/activerecord/test/cases/migrator_test.rb#L78-L85 But `db:migrate:status` doesn't work with subdirectories. It is due to `Dir.foreach(path)` is not the same with `Dir["#{path}/**/[0-9]*_*.rb"]`. I extracted `migration_files` and sharing it in the both to fix the issue. And added tests for `db:migrate:status`.
* Deprecate `supports_migrations?` on connection adaptersRyuta Kamizono2017-02-271-2/+1
| | | | | | | `supports_migrations?` was added at 4160b518 to determine if schema statements (`create_table`, `drop_table`, etc) are implemented in the adapter. But all tested databases has been supported migrations since a4fc93c3 at least.
* Remove deprecated db:test:clone* tasksRafael Mendonça França2017-01-031-24/+0
|
* Dump schema cache for custom connectionKir Shatrov2017-01-011-4/+1
| | | | | | | | | Today `rake db:schema:cache:dump` only supports dumping cache for a single connection (`ActiveRecord::Base.connection`). This doesn't work for apps with multiple databases. This PR makes `DatabaseTasks` to provide an API for dumping schema cache for any connection.
* Use YAML to serialize schema cacheKir Shatrov2016-11-271-8/+8
|
* Add three new rubocop rulesRafael Mendonça França2016-08-161-1/+1
| | | | | | | | Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
* revises most Lint/EndAlignment offensesXavier Noria2016-08-071-7/+7
| | | | Some case expressions remain, need to think about those ones.
* applies remaining conventions across the projectXavier Noria2016-08-061-8/+8
|
* normalizes indentation and whitespace across the projectXavier Noria2016-08-061-2/+2
|
* modernizes hash syntax in activerecordXavier Noria2016-08-061-41/+41
|
* applies new string literal convention in activerecord/libXavier Noria2016-08-061-63/+63
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* issue FileUtils commands directly in Rake tasksXavier Noria2016-04-111-1/+1
| | | | | Rake includes (an extended version of) FileUtils in tasks. It is more idiomatic that they use this provided interface.
* Check for protected environments before trying to load structure.sql filePrathamesh Sonpatki2016-04-101-1/+1
| | | | | | - Check for protected environments while running `db:structure:load` similar to how `db:schema:load` behaves. - Followup of https://github.com/rails/rails/pull/24399.
* Prevent db:schema:load to protected environmentsJerry Cheung2016-04-011-1/+1
| | | | | | | Follow up to https://github.com/rails/rails/pull/22967 to protect against loading a schema on accident in production. cc @schneems
* Creates development and test databases in db:migrate taskRafael Mendonça França2016-03-141-2/+2
| | | | | | | | | | | | | | | | This reverts a334425caff9b2140d5e99fcfc2eb8c4ab10bdfa. The main reason is that now the workflow is inconsistent when using spring. When using spring `RAILS_ENV` is always set, so only one database is created. This means that in development `bin/rake db:create` and `bundle exec rake db:create` have different results. It also breaks the `bin/setup` script since `bin/rake db:setup db:test:prepare` will fail.
* Add environment back to db:structure:loadAndrew White2016-01-231-1/+1
| | | | | | Because of the changes in #22967 the assumption in #18907 is no longer true because the internal metadata feature for Active Record requires a working environment.
* Allow manually setting environment valueschneems2016-01-111-0/+6
| | | | | | | | If for some reason some one is not able to set the environment from a migration this gives us an escape valve to manually set the environment for the database see https://github.com/rails/rails/pull/22967#issuecomment-170251635. We will also fix the migration case, but this will ensure there is always a way to set the environment. cc/ @sgrif
* Merge pull request #22967 from schneems/schneems/generic-metadataSean Griffin2016-01-081-5/+13
|\ | | | | Prevent destructive action on production database
| * Prevent destructive action on production databaseschneems2016-01-071-5/+13
| | | | | | | | | | | | | | This PR introduces a key/value type store to Active Record that can be used for storing internal values. It is an alternative implementation to #21237 cc @sgrif @matthewd. It is possible to run your tests against your production database by accident right now. While infrequently, but as an anecdotal data point, Heroku receives a non-trivial number of requests for a database restore due to this happening. In these cases the loss can be large. To prevent against running tests against production we can store the "environment" version that was used when migrating the database in a new internal table. Before executing tests we can see if the database is a listed in `protected_environments` and abort. There is a manual escape valve to force this check from happening with environment variable `DISABLE_DATABASE_ENVIRONMENT_CHECK=1`.
* | Refer to rails command instead of rake in a bunch of placesDavid Heinemeier Hansson2015-12-181-1/+1
|/ | | | Still more to do. Please assist!
* Revert "Merge pull request #22502 from maclover7/remove-deprecation-notice"Arthur Neves2015-12-111-0/+8
| | | | | | | This reverts commit c2e70ca9b042a3461aac0dc073a80e84bd77eb57, reversing changes made to b0e5fc2737ed0b2f67f9b9538d01e084545493fd. this broke the build
* Merge pull request #22502 from maclover7/remove-deprecation-noticeArthur Nogueira Neves2015-12-111-8/+0
|\ | | | | Remove unused deprecation notice
| * Remove unused deprecation noticeJon Moss2015-12-051-8/+0
| | | | | | | | | | The `rake db:test:*` tasks were deprecated in #13528, but were undeprecated and added back in via #17739.
* | Make `db:migrate:status` to render `1_some.rb` format migrate files.yui-knk2015-11-021-5/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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 ```
* fix typo in `db:purge` description [ci skip]yuuji.yaginuma2015-10-281-1/+1
|
* Fix out of sync commentBrandon Conway2015-09-231-1/+1
| | | 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.
* introduce `conn.data_source_exists?` and `conn.data_sources`.Yves Senn2015-09-221-1/+1
| | | | | | | | | | | | | | | | | 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)
* Merge pull request #21529 from rngtng/move-migrations-paths-to-database-taskYves Senn2015-09-091-7/+7
|\ | | | | | | Use `ActiveRecord::Tasks::DatabaseTasks.migrations_paths` explicit for db tasks
| * Use `ActiveRecord::Tasks::DatabaseTasks.migrations_paths` instead of ↵Tobias Bielohlawek2015-09-071-9/+8
|/ | | | `Migrator.migrations_paths`
* [ci skip] Replace `AR` with `Active Record` in task descyui-knk2015-09-071-1/+1
| | | | | Many user look `desc` of rake task and they are not familiar with `AR`. `Active Record` is more familiar word.
* follow-up to 2183caa, always reenable the task. #20743Yves Senn2015-06-301-3/+3
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-09 03:54:43 +0000