aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/tasks
Commit message (Collapse)AuthorAgeFilesLines
* Move DatabaseAlreadyExists detection to DB adapterJohn Hawthorn2019-07-293-13/+0
| | | | | | | | | | | | | | | | | | | | Previously it was the responsibility of the database tasks to translate the invalid statement from creating a duplicate database into an ActiveRecord::Tasks::DatabaseAlreadyExists error. It's actually easier for us to do this detection inside of the adapter, where we already do a case statement on the return code to translate the error. This commit introduces ActiveRecord::DatabaseAlreadyExists, a subclass of StatementInvalid, and updates both AbstractMysqlAdapter and PostgresqlAdapter to return this more specific exception in that case. Because this is a subclass of the old exception, StatementInvalid, it should be backwards compatible with any code expecting that from create_database. This works for both create_database and exectute("CREATE DATABASE")
* Use connection.error_number in MySQLDatabaseTasksJohn Hawthorn2019-07-251-1/+1
| | | | | | | | | | | MySQLDatabaseTasks, like AbstractMysqlAdapter, should be able to operate on any mysql adapter, not just mysql2. Errors having a .error_number attribute is a mysql2 specific API, which we (Rails) don't control, so we should instead use connection.error_number(err), which we do. This also updates tests to better test how this really works, previously it stubbed create_database to raise Tasks::DatabaseAlreadyExists, which can never happen.
* Make sure AR can load without Railseileencodes2019-07-251-0/+2
| | | | | | | | In #36560 I accidentally re-introduced a bug where ActiveRecord can't be used without Rails. This returns an empty hash if we're outside the context of Rails since we can't create the database tasks without loading and reading the database yaml which is something only Railties can do.
* MySQL: Check error number instead of a messageyuuji.yaginuma2019-07-111-1/+3
| | | | To be able to check regardless of locale.
* Load initial database.yml once, and warn if we can't create taskseileencodes2019-06-271-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move SchemaMigration to migration_contexteileencodes2019-06-141-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This PR moves the `schema_migration` to `migration_context` so that we can access the `schema_migration` per connection. This does not change behavior of the SchemaMigration if you are using one database. This also does not change behavior of any public APIs. `Migrator` is private as is `MigrationContext` so we can change these as needed. We now need to pass a `schema_migration` to `Migrator` so that we can run migrations on the right connection outside the context of a rake task. The bugs this fixes were discovered while debugging the issues around the SchemaCache on initialization with multiple database. It was clear that `get_all_versions` wouldn't work without these changes outside the context of a rake task (because in the rake task we establish a connection and change AR::Base.connection to the db we're running on). Because the `SchemaCache` relies on the `SchemaMigration` information we need to make sure we store it per-connection rather than on ActiveRecord::Base. [Eileen M. Uchitelle & Aaron Patterson]
* Enable `Layout/EmptyLinesAroundAccessModifier` copRyuta Kamizono2019-06-133-3/+0
| | | | | | | | | | | We sometimes say "✂️ newline after `private`" in a code review (e.g. https://github.com/rails/rails/pull/18546#discussion_r23188776, https://github.com/rails/rails/pull/34832#discussion_r244847195). Now `Layout/EmptyLinesAroundAccessModifier` cop have new enforced style `EnforcedStyle: only_before` (https://github.com/rubocop-hq/rubocop/pull/7059). That cop and enforced style will reduce the our code review cost.
* Add forgotten nodoc to dump_schema method.Wojciech Wnętrzak2019-06-071-1/+1
| | | | Method added in https://github.com/rails/rails/pull/36416
* Fixed db:prepare task for multiple databases.Wojciech Wnętrzak2019-06-051-3/+25
| | | | | When one database existed already, but not the other, during setup of missing one, existing database was wiped out.
* Handle up/down for multiple databaseseileencodes2019-04-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+2
| | | | | | | | | | | | | | | | 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.
* Respect table name prefix/suffix for `truncate_all`Ryuta Kamizono2019-04-041-2/+2
|
* Tweak `truncate_tables`Ryuta Kamizono2019-03-181-1/+1
| | | | | | * Remove redundant `table_names.empty?` * Early return in `truncate_tables` since it is already deeply nested * Move `truncate_tables` out from between `exec_delete` and `exec_update`
* Make `truncate_tables` to bulk statementsRyuta Kamizono2019-03-171-3/+1
| | | | | | | | | | | | | | | | | | Before: ``` (16.4ms) TRUNCATE TABLE `author_addresses` (20.5ms) TRUNCATE TABLE `authors` (19.4ms) TRUNCATE TABLE `posts` ``` After: ``` Truncate Tables (19.5ms) TRUNCATE TABLE `author_addresses`; TRUNCATE TABLE `authors`; TRUNCATE TABLE `posts` ```
* Extract `truncate` and `truncate_tables` into database statementsRyuta Kamizono2019-03-174-34/+5
| | | | This is to easier make `truncate_tables` to bulk statements.
* Load YAML for rake tasks without parsing ERBeileencodes2019-03-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a new method that loads the YAML for the database config without parsing the ERB. This may seem odd but bear with me: When we added the ability to have rake tasks for multiple databases we started looping through the configurations to collect the namespaces so we could do `rake db:create:my_second_db`. See #32274. This caused a problem where if you had `Rails.config.max_threads` set in your database.yml it will blow up because the environment that defines `max_threads` isn't loaded during `rake -T`. See #35468. We tried to fix this by adding the ability to just load the YAML and ignore ERB all together but that caused a bug in GitHub's YAML loading where if you used multi-line ERB the YAML was invalid. That led us to reverting some changes in #33748. After trying to resolve this a bunch of ways `@tenderlove` came up with replacing the ERB values so that we don't need to load the environment but we also can load the YAML. This change adds a DummyCompiler for ERB that will replace all the values so we can load the database yaml and create the rake tasks. Nothing else uses this method so it's "safe". DO NOT use this method in your application. Fixes #35468
* Allow `truncate` for SQLite3 adapter and add `rails db:seed:replant` (#34779)Bogdan2019-03-044-0/+50
| | | | | | | | | | | | | * 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
* Add multi-db support to schema cache dump and clearGannon McGibbon2018-11-071-0/+10
| | | | | Adds support for multiple databases to `rails db:schema:cache:dump` and `rails db:schema:cache:clear`.
* Move db:migrate:status to DatabaseTasks methodGannon McGibbon2018-10-081-0/+15
|
* Add `Style/RedundantFreeze` to remove redudant `.freeze`Yasuo Honda2018-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | Since Rails 6.0 will support Ruby 2.4.1 or higher `# frozen_string_literal: true` magic comment is enough to make string object frozen. This magic comment is enabled by `Style/FrozenStringLiteralComment` cop. * Exclude these files not to auto correct false positive `Regexp#freeze` - 'actionpack/lib/action_dispatch/journey/router/utils.rb' - 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb' It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333 Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed. * Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required - 'actionpack/test/controller/test_case_test.rb' - 'activemodel/test/cases/type/string_test.rb' - 'activesupport/lib/active_support/core_ext/string/strip.rb' - 'activesupport/test/core_ext/string_ext_test.rb' - 'railties/test/generators/actions_test.rb'
* Use -X when loading structure.sql via psqlJ Smith2018-09-271-1/+1
|
* Removed invalid -X flag for pg_dumpMatthias Winkelmann2018-09-271-1/+1
|
* Enable `Performance/UnfreezeString` copyuuji.yaginuma2018-09-234-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Ruby 2.3 or later, `String#+@` is available and `+@` is faster than `dup`. ```ruby # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |x| x.report('+@') { +"" } x.report('dup') { "".dup } x.compare! end ``` ``` $ ruby -v benchmark.rb ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] Warming up -------------------------------------- +@ 282.289k i/100ms dup 187.638k i/100ms Calculating ------------------------------------- +@ 6.775M (± 3.6%) i/s - 33.875M in 5.006253s dup 3.320M (± 2.2%) i/s - 16.700M in 5.032125s Comparison: +@: 6775299.3 i/s dup: 3320400.7 i/s - 2.04x slower ```
* Ignore psqlrc files when executing psql commandsJ Smith2018-09-171-1/+1
| | | | | | psqlrc files can affect the execution of commands in ways that can hold up execution by blocking or otherwise cause unexpected side effects and should best be ignored when using psql programmatically.
* Convert configs_for to kwargs, add include_replicasEileen Uchitelle2018-08-311-5/+5
| | | | | | | | | | | 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-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge pull request #33744 from bogdanvlviv/fixes-27852Ryuta Kamizono2018-08-301-1/+1
|\ | | | | Prevent leaking of user's DB credentials on `rails db:create` failure
| * Prevent leaking of user's DB credentials on `rails db:create` failurebogdanvlviv2018-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue #27852 reports that when `rails db:create` fails, it causes leaking of user's DB credentials to $stderr. We print a DB's configuration hash in order to help users more quickly to figure out what could be wrong with his configuration. This commit changes message from "Couldn't create database for #{configuration.inspect}" to "Couldn't create '#{configuration['database']}' database. Please check your configuration.". There are two PRs that fixing it #27878, #27879, but they need a bit more work. I decided help to finish this and added Author of those PRs credit in this commit. Since it is a security issue, I think we should backport it to `5-2-stable`, and `5-1-stable`. Guided by https://edgeguides.rubyonrails.org/maintenance_policy.html#security-issues Fixes #27852 Closes #27879 Related to #27878 [Alexander Marrs & bogdanvlviv]
* | Drop load_database_yaml and fix testEileen Uchitelle2018-08-291-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | We originally did the whole `load_database_yaml` thing because this test wasn't cooperating and we needed to finish the namespaced rake tasks for multiple databases. However, it turns out that YAML can't eval ERB if you don't tell it it's ERB so you get Pysch parse errors if you're using multi-line ERB or ERB with conditionals. It's a hot mess. After trying a few things and thinking it over we decided that it wasn't worth bandaiding over, the test needed to be improved. The test was added in #31135 to test that the env is loaded in these tasks. But it was blowing up because we were trying to read a database name out of the configuration - however that's not the purpose of this change. We want to read environment files in the rake tasks, but not in the config file. In this PR we changed the test to test what the PR was actually fixing. We've also deleted the `load_database_yaml` because it caused more problems than it was worth. This should fix the issues described in https://github.com/rails/rails/pull/32274#issuecomment-384161057. We also had these problems at GitHub. Co-authored-by: alimi <aibrahim2k2@gmail.com>
* [ci skip] Change references from Rake task to Rails commandAlberto Almagro2018-08-011-1/+1
| | | | | This commit follows the path we started at commit #ea4f0e2 and continued at PR #33229.
* use load_schema instead of migrate for parallel testingBritni Alexander2018-07-311-0/+3
|
* Turn on performance based copsDillon Welch2018-07-233-13/+3
| | | | | | | | | | | | | | | | Use attr_reader/attr_writer instead of methods method is 12% slower Use flat_map over map.flatten(1) flatten is 66% slower Use hash[]= instead of hash.merge! with single arguments merge! is 166% slower See https://github.com/rails/rails/pull/32337 for more conversation
* Don't create namespaced tasks if single db applicationeileencodes2018-04-091-2/+7
| | | | | | This was causing single db applications to have rake tasks named `db:create:primary`. These tasks are only useful to multiple database applications so they shouldn't be generated.
* Allow schema/structure load for multiple databaseseileencodes2018-04-091-3/+3
| | | | | Pass the spec name to load_schema in order to load from the correct structure file when there are multiple databases
* Refactor configs_for and friendseileencodes2018-03-211-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+16
| | | | | | | 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-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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.
* Don't expose `verbose?` helper methodRyuta Kamizono2018-03-021-6/+4
| | | | | | Follow up of b988ecb99ff6c8854e4b74ef8a7ade8d9ef5d954. This was added for internal usage, it doesn't need to be public.
* Revert "Merge pull request #32075 from eileencodes/delete-default-configuration"eileencodes2018-02-221-0/+4
| | | | | | | | | | This reverts commit 16f279ebd474626577ced858e3626ac4535a33df, reversing changes made to 6c6a30a7c357ce1eafa093d77d2b08684fe50887. The config can be named anything, not just default (although all generated apps will be named default). We can't just delete configs that don't have a database because that will break three-tier configs. Oh well.
* Delete default configurationeileencodes2018-02-211-4/+0
| | | | | | | Because of this default configuration we're constantly checking if the database exists when looping through configurations. This is unnecessary and we should just delete it before we need to loop through configurations.
* Don't output information on drop if not verboseeileencodes2018-02-051-1/+1
| | | | | Followup to b988ecb, when I cherry-picked from my parallel testing branch I didn't realize `drop` wasn't part of the commit.
* Add ability to turn off verbose for database taskseileencodes2018-02-051-3/+7
| | | | | | | | | | | | | | | You could use the `VERBOSE` env var to turn off output for migrations tasks but you couldn't use it for other tasks. This change moves the `verbose?` check to a method so we can also use it in create and drop respectively. tenderlove and I noticed this as part of the ongoing work in parallel testing. When the parallel tests boot the app needs to create new databases for each worker. The output from these is unnecessary but there was previously no way to turn it off. Now if `VERBOSE=false` is passes to `bin/rails db:create` the text "Created blah blah db" will no longer be output.
* Remove unused `migration_context` in `DatabaseTasks`Ryuta Kamizono2018-01-191-4/+0
| | | | This was added in #31727, but it is unused.
* Refactor migration to move migrations paths to connectioneileencodes2018-01-181-4/+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.
* Merge pull request #30414 from bogdanvlviv/clear-mysql_database_tasksRafael França2017-11-091-47/+0
|\ | | | | Simplify implementation of `MySQLDatabaseTasks`
| * Simplify implementation of `MySQLDatabaseTasks`bogdanvlviv2017-10-301-45/+0
| | | | | | | | | | | | Don't process MySQL ERROR 1045, raise error instead Make behavior of `MySQLDatabaseTasks` more consistent with behavior of `PostgreSQLDatabaseTasks`
| * Raise error if unsupported charset for mysqlbogdanvlviv2017-10-301-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `blog$ bin/rails db:create` Before: ``` Couldn't create database for {"adapter"=>"mysql2", "encoding"=>"utf42", "pool"=>5, "username"=>"root", "password"=>nil, "socket"=>"/var/run/mysqld/mysqld.sock", "database"=>"blog_development"}, {:charset=>"utf42"} (If you set the charset manually, make sure you have a matching collation) Created database 'blog_development' Couldn't create database for {"adapter"=>"mysql2", "encoding"=>"utf42", "pool"=>5, "username"=>"root", "password"=>nil, "socket"=>"/var/run/mysqld/mysqld.sock", "database"=>"blog_test"}, {:charset=>"utf42"} (If you set the charset manually, make sure you have a matching collation) Created database 'blog_test' ``` After: ``` Unsupported charset: '"utf42"' Couldn't create database for {"adapter"=>"mysql2", "encoding"=>"utf42", "pool"=>5, "username"=>"root", "password"=>nil, "socket"=>"/var/run/mysqld/mysqld.sock", "database"=>"blog_development"} rails aborted! Mysql2::Error: Unsupported charset: '"utf42"' ... (stack trace) ... bin/rails:4:in `<main>' Tasks: TOP => db:create (See full trace by running task with --trace) ``` Closes #29683 Related to #27398
* | Fix `bin/rails db:migrate` with specified `VERSION`bogdanvlviv2017-11-061-3/+12
|/ | | | | | 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-1/+1
| | | | This basically reverts 9d4f79d3d394edb74fa2192e5d9ad7b09ce50c6d
* `ActiveRecord::Tasks::DatabaseTasks.load_schema` has always to establish ↵bogdanvlviv2017-10-151-3/+3
| | | | | | | | | | | | database connection When load schema from `structure.sql`, database connection isn't established. `ActiveRecord::Tasks::DatabaseTasks.load_schema` has to establish database connection since it executes ``` ActiveRecord::InternalMetadata.create_table ActiveRecord::InternalMetadata[:environment] = environment ```
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 11:25:05 +0000