aboutsummaryrefslogtreecommitdiffstats
path: root/railties/test/application/rake
Commit message (Collapse)AuthorAgeFilesLines
* Fixed db:prepare task to not touch schema when dump_schema_after_migration ↵Wojciech Wnętrzak2019-07-241-0/+16
| | | | is false.
* Load initial database.yml once, and warn if we can't create taskseileencodes2019-06-271-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Enable `Layout/EmptyLinesAroundAccessModifier` copRyuta Kamizono2019-06-131-1/+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.
* Convert the db:abort_if_pending_migrations task to be multi-DB awareMark Lee2019-06-101-0/+26
|
* Fixed db:prepare task for multiple databases.Wojciech Wnętrzak2019-06-051-0/+20
| | | | | When one database existed already, but not the other, during setup of missing one, existing database was wiped out.
* Fix: DummyCompiler embeds invalid YAML contentVishal Telangre2019-05-151-0/+17
| | | | | | Fixes https://github.com/rails/rails/issues/36285. Follow up of https://github.com/rails/rails/pull/36237.
* Fix database loading when ERB is single line ternaryeileencodes2019-05-101-0/+16
| | | | | | | | | | | | *sigh* this seems like the never ending bug. I don't love or even like this fix but it does _work_. Rafael suggested using `dummy_key: dummy_value` but unfortunately that doesn't work. So we're left with checking whethere there might be ternary type things in the content and then assuming that we want to replace the line with a key value pair. Technically fixes https://github.com/rails/rails/issues/36088
* Handle up/down for multiple databaseseileencodes2019-04-191-1/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. ```
* Remove the Amazon SES ingressGeorge Claghorn2019-04-141-1/+0
| | | It's unusable and not ready to ship in Rails 6.0. We'll rewrite it for 6.1.
* Merge pull request #35768 from robertomiranda/r/rake-db-prepareEileen M. Uchitelle2019-04-022-0/+36
|\ | | | | Add db:prepare rake task.
| * Add migration in case of db:drop assertionRoberto Miranda2019-04-021-0/+7
| |
| * 💇Roberto Miranda2019-04-022-2/+1
| |
| * Add test cases for rake db:prepareRoberto Miranda2019-04-022-0/+30
| |
* | url -> URL where apt except inside actionpack/Sharang Dashputre2019-04-011-2/+2
|/
* Add additional ERB DummyCompiler testsCliff Pruitt2019-03-121-0/+54
| | | | This adds a few additional tests to the commits by eileencodes (https://github.com/rails/rails/pull/35497) and rafaelfranca (https://github.com/rails/rails/commit/cfa22f1a4b5e8b95ee01a432168de2f831b3f788). The additional tests cover several more ERB tag formatting cases such as multiline tags, conditional statements that result in duplicate keys, and multiple erb statements on a single line.
* Do not generate dummy string when the tag used is not the <%=Rafael Mendonça França2019-03-111-0/+1
|
* Minor text changes to the db:seed:replant testsSharang Dashputre2019-03-091-2/+2
|
* Load YAML for rake tasks without parsing ERBeileencodes2019-03-061-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-1/+121
| | | | | | | | | | | | | * 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
* let Zeitwerk integration unhook AS::DependenciesXavier Noria2019-02-192-2/+5
|
* Respect ENV variables when finding DBs etc for the test suiteMatthew Draper2019-02-061-0/+2
| | | | | If they're not set we'll still fall back to localhost, but this makes it possible to run the tests against a remote Postgres / Redis / whatever.
* Add Exim and Qmail support to Action MailboxGeorge Claghorn2019-01-121-1/+1
|
* Added Postmark ingress supportTomek Maszkowski2019-01-091-0/+1
|
* Import Action MailboxGeorge Claghorn2018-12-251-7/+22
|
* Enable `Style/RedundantBegin` cop to avoid newly adding redundant begin blockRyuta Kamizono2018-12-211-15/+13
| | | | | | | | | | 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.
* Remove unused argument `expected_database`bogdanvlviv2018-11-081-5/+5
| | | | This argument was added in fa5a028ed9f, and #34137 but hasn't been used.
* Add multi-db support to schema cache dump and clearGannon McGibbon2018-11-071-0/+31
| | | | | 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-19/+51
|
* Make sure this test check the issue solved in #31135Rafael Mendonça França2018-09-221-6/+12
| | | | | | | | | | | | | | | Before this change this test was passing even if we revert #31135. The reason for that is that `app 'development'` will load the environment in the test process and it is happening before db_create_and_drop is called. This was not asserting that the environment was loaded in the db:create task itself. To test it we enhance the db:create task with a block that writes to a tmp file the value of the config. If the environment is loaded before that task enhancement runs the content of the file will have "true" insteand of "false".
* Respect config setting when output deprecation notice in rake tasksyuuji.yaginuma2018-09-044-1/+4
| | | | | | | | | The rake tasks which became deprecate now does not load the environment. Therefore, even if the application specifies the behavior of deprecating, the message is output to stderr ignoring the specification. It seems that this is not the expected behavior. We should respect the setting even in the rake tasks.
* Convert configs_for to kwargs, add include_replicasEileen Uchitelle2018-08-311-7/+10
| | | | | | | | | | | 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-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* | Remove this conditionalEileen Uchitelle2018-08-291-1/+1
| | | | | | | | I removed the argument so I should remove the conditional too.
* | Remove unused argumentEileen Uchitelle2018-08-291-1/+1
| | | | | | | | The test that used this was updated and it's no longer needed.
* | Drop load_database_yaml and fix testEileen Uchitelle2018-08-291-3/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make `rake routes` deprecate before deletingyuuji.yaginuma2018-08-201-0/+44
| | | | | | | `rake routes` was a public task. Therefore, I think that we should deprecate it before deleting it. Related to #32121.
* Update 'rake initializers' to use Rails::Command under the hoodAnnie-Claude Côté2018-08-161-0/+42
| | | | | | * Invoke Rails::Command within the rake task * Adds test for calling initializers with 'bin/rake' * Adds deprecation warning to the rake task
* Have `bin:rake dev:cache` use the Dev Rails Command under the hoodAnnie-Claude Côté2018-08-131-15/+28
| | | | | * Call the Rails::Command::DevCommand in the rake task for dev:cache * Add deprecation for using `bin/rake` in favor of `bin/rails`
* Clarify `railties/test/application/rake/notes_test.rb`bogdanvlviv2018-07-211-59/+58
| | | | | | | | | | | | | After 1996fbe2a3e46ff5698bfa3812afb7f42cdfa899 `rails notes` isn't the same as `rake notes`. Since that, we should test `rake routes` instead of `rails notes` in `railties/test/application/rake/notes_test.rb` file. So I changed all occurrences of `rails routes` to `rake routes` in that file, and added assertions about deprecation warning of using `rake notes`. It will help to figure out that we should remove `railties/test/application/rake/notes_test.rb` entirely in favour of `railties/test/commands/notes_test.rb` that was added in 1996fbe2a3e46ff5698bfa3812afb7f42cdfa899.
* Fix deprecation message for `SOURCE_ANNOTATION_DIRECTORIES`yuuji.yaginuma2018-07-201-0/+3
| | | | Also, added a test that a deprecated message will be output.
* Fix `CustomCops/AssertNot` to allow it to have failure messageRyuta Kamizono2018-05-131-1/+1
| | | | Follow up of #32605.
* Replace `assert !` with `assert_not`Daniel Colson2018-04-192-3/+3
| | | | | This autocorrects the violations after adding a custom cop in 3305c78dcd.
* Fix test to allow IF NOT EXISTS in structure:dumputilum2018-04-161-2/+2
| | | | | | | | | | | | | | | | | | Before: ``` $ ruby -v ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] $ ruby -w -Itest -Ilib -I../activesupport/lib -I../actionpack/lib -I../actionview/lib -I../activemodel/lib test/application/rake/multi_dbs_test.rb Run options: --seed 28744 F Failure: ApplicationTests::RakeTests::RakeMultiDbsTest#test_db:migrate_and_db:structure:dump_and_db:structure:load_works_on_all_databases [test/application/rake/multi_dbs_test.rb:70]: Expected /CREATE TABLE \"books\"/ to match "CREATE TABLE IF NOT EXISTS \"schema_migrations\" (\"version\" varchar NOT NULL PRIMARY KEY);\nCREATE TABLE IF NOT EXISTS \"ar_internal_metadata\" (\"key\" varchar NOT NULL PRIMARY KEY, \"value\" varchar, \"created_at\" datetime NOT NULL, \"updated_at\" datetime NOT NULL);\nCREATE TABLE IF NOT EXISTS \"books\" (\"id\" integer PRIMARY KEY AUTOINCREMENT NOT NULL, \"title\" varchar, \"created_at\" datetime NOT NULL, \"updated_at\" datetime NOT NULL);\nCREATE TABLE sqlite_sequence(name,seq);\nINSERT INTO \"schema_migrations\" (version) VALUES\n('20180416201805');\n\n\n". ```
* Add multidb application testeileencodes2018-04-091-0/+164
| | | | | | | | | I realized I wasn't really testing some of the new rake tasks added so I built out this new test that uses a multi-db database.yml and allows us to run create/drop/migrate/schema:dump/schema:load and those that are namespaced like create:animals. This will make our testing more robust so we can catch problems quicker and set a good place to add future tests as these features evolve.
* Move SourceAnnotationExtractor under Rails modulePrem Sichanugrist2018-03-221-1/+1
| | | | This class should be under Rails module as it belongs to Rails.
* Add test to properly test down with a blockeileencodes2018-01-181-0/+8
| | | | | | | | | | | | down is only called with a block from the rake tasks where it passes a `SCOPE`. Technically this was tested but since we don't run all the migrations we're not actually testing the down works with a `SCOPE`. To ensure we're testing both we can run `db:migrate` again to migrate users and then run `down` with a scope to test that only the bukkits migration is reverted. Updates test to prevent having to fix regressions like we did in 4d4db4c.
* Refactor migration to move migrations paths to connectioneileencodes2018-01-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Enable `Layout/LeadingCommentSpace` to not allow cosmetic changes in the futureRyuta Kamizono2017-12-141-2/+2
| | | | Follow up of #31432.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 04:57:07 +0000