aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/railties
Commit message (Collapse)AuthorAgeFilesLines
* Fix db:seedeileencodes2019-07-311-0/+2
| | | | | | | | | | | | | | | | | | | The `rake db:seed` command was broken for the primary environment if the application is using multiple databases. We never implemented `rake db:seed` for other databases (coming soon), but that shouldn't break the default case. The reason this was broken was because `abort_if_pending_migrations` would loop through the configs for all databases and check for migrations but would leave the last established connection. So `db:seed` was looking in the wrong database for the table to seed. This PR doesn't fix the fact that `db:seed` doesn't work for multiple databases but does fix the default case. Fixes #36817 Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
* Fixed db:prepare task to not touch schema when dump_schema_after_migration ↵Wojciech Wnętrzak2019-07-241-3/+4
| | | | is false.
* Include common commands in rails help outputTekin Suleyman2019-07-191-4/+4
| | | | | | With their descriptions commented out these commands were not included in the rails help command's output, which is a shame as they are useful, particularly during the development of more complex migrations.
* Load initial database.yml once, and warn if we can't create taskseileencodes2019-06-271-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | For multiple databases we attempt to generate the tasks by reading the database.yml before the Rails application is booted. This means that we need to strip out ERB since it could be reading Rails configs. In some cases like https://github.com/rails/rails/issues/36540 the ERB is too complex and we can't overwrite with the DummyCompilier we used in https://github.com/rails/rails/pull/35497. For the complex causes we simply issue a warning that says we couldn't infer the database tasks from the database.yml. While working on this I decided to update the code to only load the database.yml once initially so that we avoid having to issue the same warning multiple times. Note that this had no performance impact in my testing and is merely for not having to save the error off somewhere. Also this feels cleaner. Note that this will not break running tasks that exist, it will just mean that tasks for multi-db like `db:create:other_db` will not be generated. If the database.yml is actually unreadable it will blow up during normal rake task calls. Fixes #36540
* Convert the db:abort_if_pending_migrations task to be multi-DB awareMark Lee2019-06-101-1/+25
|
* Fixed db:prepare task for multiple databases.Wojciech Wnętrzak2019-06-051-16/+24
| | | | | When one database existed already, but not the other, during setup of missing one, existing database was wiped out.
* Remove description for namespaced `db:migrate:up`eileencodes2019-04-191-1/+0
| | | | | This was accidentally left in, the standard `db:migrate:up` doesn't have a description so `db:migrate:up:namespace` shouldn't have one either.
* Handle up/down for multiple databaseseileencodes2019-04-191-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds the ability to run up/down for a database in a multi-db environment. If you have an app with a primary and animals database the following tasks will be generated: ``` VERSION=123 rake db:migrate:up:primary VERSION=123 rake db:migrate:up:primary VERSION=123 rake db:migrate:down:primary VERSION=123 rake db:migrate:up:animals ``` I didn't generate descriptions with them since we don't generate a description for a single database application. In addition to this change I've made it so if your application has multiple databases Rails will raise if you try to run `up` or `down` without a namespace. This is because we don't know which DB you want to run `up` or `down` against unless the app tells us, so it's safer to just block it and recommend using namespaced versions of up/down respectively. The output for the raise looks like: ``` You're using a multiple database application. To use `db:migrate:down` you must run the namespaced task with a VERSION. Available tasks are db:migrate:down:primary and db:migrate:down:animals. ```
* Ensure active record can load without Railtieseileencodes2019-04-181-7/+7
| | | | | | | | | | | | | | | | When I added the rake tasks for multiple databases I accidentally made it so you couldn't use Active Record without Railties. Since getting the database configuration depends on being able to load Railties (there is no other way to read and parse the yaml file and load it) I've decided that using multiple databases outside of Rails is a no-op. I've changed the code here to return if Rails isn't defined. Then I changed the other tasks to use `ActiveRecord::Tasks::DatabaseTasks.env` instead of `Rails.env`. The multi-db tasks can keep using `Rails.env` because they'll only be generated if we're using Rails and not just Active Record.
* 💇Roberto Miranda2019-04-021-6/+4
|
* Add test cases for rake db:prepareRoberto Miranda2019-04-021-6/+9
|
* Move db:migrate call to else blockRoberto Miranda2019-03-271-1/+2
|
* Improve db:prepare descriptionRoberto Miranda2019-03-271-1/+1
|
* Add rake db:prepare rake task.Roberto Miranda2019-03-271-0/+8
| | | | | | | It Creates the database, loads the schema, run the migrations and initializes with the seed data (use db:reset to also drop the database first). This rake task runs in an idempotent way ref https://github.com/rails/rails/pull/33139#discussion_r195930751
* Allow `truncate` for SQLite3 adapter and add `rails db:seed:replant` (#34779)Bogdan2019-03-041-0/+10
| | | | | | | | | | | | | * Add `ActiveRecord::Base.connection.truncate` for SQLite3 adapter. SQLite doesn't support `TRUNCATE TABLE`, but SQLite3 adapter can support `ActiveRecord::Base.connection.truncate` by using `DELETE FROM`. `DELETE` without `WHERE` uses "The Truncate Optimization", see https://www.sqlite.org/lang_delete.html. * Add `rails db:seed:replant` that truncates database tables and loads the seeds Closes #34765
* Speed up partial rendering by caching "variable" calculationAaron Patterson2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit speeds up rendering partials by caching the variable name calculation on the template. The variable name is based on the "virtual path" used for looking up the template. The same virtual path information lives on the template, so we can just ask the cached template object for the variable. This benchmark takes a couple files, so I'll cat them below: ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat render_benchmark.rb require "benchmark/ips" require "action_view" require "action_pack" require "action_controller" class TestController < ActionController::Base end TestController.view_paths = [File.expand_path("test/benchmarks")] controller_view = TestController.new.view_context result = Benchmark.ips do |x| x.report("render") do controller_view.render("many_partials") end end [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_many_partials.html.erb Looping: <ul> <% 100.times do |i| %> <%= render partial: "list_item", locals: { i: i } %> <% end %> </ul> [aaron@TC ~/g/r/actionview (speed-up-partials)]$ cat test/benchmarks/test/_list_item.html.erb <li>Number: <%= i %></li> ``` Benchmark results (master): ``` [aaron@TC ~/g/r/actionview (master)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 41.000 i/100ms Calculating ------------------------------------- render 424.269 (± 3.5%) i/s - 2.132k in 5.031455s ``` Benchmark results (this branch): ``` [aaron@TC ~/g/r/actionview (speed-up-partials)]$ be ruby render_benchmark.rb Warming up -------------------------------------- render 50.000 i/100ms Calculating ------------------------------------- render 521.862 (± 3.8%) i/s - 2.650k in 5.085885s ```
* Pull `@template` in to a local variableAaron Patterson2019-01-281-2/+2
| | | | | | This gets the PartialRenderer to be a bit closer to the TemplateRenderer. TemplateRenderer already keeps its template in a local variable.
* Remove `@view` instance variable from the partial rendererAaron Patterson2019-01-281-2/+2
| | | | Similar to 1853b0d0abf87dfdd4c3a277c3badb17ca19652e
* Add foreign key to active_storage_attachments for `blob_id` via new migrationbogdanvlviv2019-01-161-0/+4
| | | | | | | | | | | | | | | | | | We need this in order to be able to add this migration for users that use ActiveStorage during update their apps from Rails 5.2 to Rails 6.0. Related to #33405 `rake app:update` should update active_storage `rake app:update` should execute `rake active_storage:update` if it is used in the app that is being updated. It will add new active_storage's migrations to users' apps during update Rails. Context https://github.com/rails/rails/pull/33405#discussion_r204239399 Also, see a related discussion in the Campfire: https://3.basecamp.com/3076981/buckets/24956/chats/12416418@1236713081
* Enable `Style/RedundantBegin` cop to avoid newly adding redundant begin blockRyuta Kamizono2018-12-211-16/+12
| | | | | | | | | | Currently we sometimes find a redundant begin block in code review (e.g. https://github.com/rails/rails/pull/33604#discussion_r209784205). I'd like to enable `Style/RedundantBegin` cop to avoid that, since rescue/else/ensure are allowed inside do/end blocks in Ruby 2.5 (https://bugs.ruby-lang.org/issues/12906), so we'd probably meets with that situation than before.
* Add multi-db support to schema cache dump and clearGannon McGibbon2018-11-071-5/+12
| | | | | Adds support for multiple databases to `rails db:schema:cache:dump` and `rails db:schema:cache:clear`.
* Add multi-db support to rails db:migrate:statusGannon McGibbon2018-10-091-1/+15
|
* Move db:migrate:status to DatabaseTasks methodGannon McGibbon2018-10-081-12/+1
|
* 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 ```
* Only preload misses on multifetch cacheLachlan Sylvester2018-03-061-0/+34
|
* 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`.
* Rails 6 requires Ruby 2.3+Jeremy Daer2018-02-171-35/+30
|
* 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
* Merge pull request #30414 from bogdanvlviv/clear-mysql_database_tasksRafael França2017-11-091-18/+0
|\ | | | | Simplify implementation of `MySQLDatabaseTasks`
| * Simplify implementation of `MySQLDatabaseTasks`bogdanvlviv2017-10-301-18/+0
| | | | | | | | | | | | Don't process MySQL ERROR 1045, raise error instead Make behavior of `MySQLDatabaseTasks` more consistent with behavior of `PostgreSQLDatabaseTasks`
* | 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-212-4/+4
| | | | 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-194-0/+8
|
* [Active Record] require => require_relativeAkira Matsuda2017-07-012-4/+4
|
* 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 13:07:09 +0000