aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | Validate if `utf8mb4` character set and longer index key prefix is supportedYasuo Honda2018-09-131-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once #33608 merged If users create a new database using MySQL 5.1.x, it will fail to create databases since MySQL 5.1 does not know `utf8mb4` character set. This pull request removes `encoding: utf8mb4` from `mysql.yml.tt` to let create_database method handles default character set by MySQL server version. `supports_longer_index_key_prefix?` method will need to validate if MySQL 5.5 and 5.6 server configured correctly to support longer index key prefix, but not yet.
* | | | | Merge pull request #33844 from kamipo/too_many_eager_load_idsRyuta Kamizono2018-09-132-5/+10
|\ \ \ \ \ | |/ / / / |/| | | | Eager loading/preloading should be worked regardless of large number of records
| * | | | Eager loading/preloading should be worked regardless of large number of recordsRyuta Kamizono2018-09-122-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 213796f, bind params are used for IN clause if enabled prepared statements. Unfortunately, most adapter modules have a limitation for # of bind params (mysql2 65535, pg 65535, sqlite3 250000). So if eager loading large number of records at once, that query couldn't be sent to the database. Since eager loading/preloading queries are auto-generated by Active Record itself, so it should be worked regardless of large number of records like as before. Fixes #33702.
* | | | | Add mention about `ActiveRecord::Base::filter_attributes` to the changelog entrybogdanvlviv2018-09-121-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Also remove `# :nodoc:` for `ActiveRecord::Core::ClassMethods` in order to show non-nodoc methods in that module on the api docs http://edgeapi.rubyonrails.org
* | | | | Build string set when `filter_attributes` is assignedbogdanvlviv2018-09-121-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It would allow `filter_attributes` to be reused across multiple calls to `#inspect` or `#pretty_print`. - Add `require "set"` - Remove `filter_attributes` instance reader. I think there is no need to keep it.
* | | | | DRY `activerecord/lib/active_record/core.rb` and fix testsbogdanvlviv2018-09-121-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Move ``` filter_attributes = self.filter_attributes.map(&:to_s).to_set filter_attributes.include?(attribute_name) && !read_attribute(attribute_name).nil? ``` to private method. - Fix tests in `activerecord/test/cases/filter_attributes_test.rb` - Ensure that `teardown` sets `ActiveRecord::Base.filter_attributes` to previous state. - Ensure that `Admin::Account.filter_attributes` is set to previous state in the "filter_attributes could be overwritten by models" test. Follow up #33756
* | | | | Clarify docs of `config.filter_parameters` and `#filter_attributes`bogdanvlviv2018-09-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Add mention that `config.filter_parameters` also filters out sensitive values of database columns when call `#inspect` since #33756.
* | | | | Fix query cache to load before first requestEileen Uchitelle2018-09-121-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a test app we observed that the query cache was not enabled on the first request. This was because the query cache hooks are installed on load and active record is loaded in the middle of the first request. If we remove the `on_load` from the railtie the query cache hooks will be installed before the first request, allowing the cache to be enabled on that first request. This is ok because query cache doesn't load anything else, only itself so we're not eager loading all of active record before the first request, just the query cache hooks. [Eileen M. Uchitelle & Matthew Draper]
* | | | | Use utf8mb4 character set by default for MySQL database (#33608)Yasuo Honda2018-09-111-2/+2
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Use utf8mb4 character set by default `utf8mb4` character set supports supplementary characters including emoji. `utf8` character set with 3-Byte encoding is not enough to support them. There was a downside of 4-Byte length character set with MySQL 5.5 and 5.6: "ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes" for Rails string data type which is mapped to varchar(255) type. MySQL 5.7 supports 3072 byte key prefix length by default. * Remove `DEFAULT COLLATE` from Active Record unit test databases There should be no "one size fits all" collation in MySQL 5.7. Let MySQL server choose the default collation for Active Record unit test databases. Users can choose their best collation for their databases by setting `options[:collation]` based on their requirements. * InnoDB FULLTEXT indexes support since MySQL 5.6 it does not have to use MyISAM storage engine whose maximum key length is 1000 bytes. Using MyISAM storag engine with utf8mb4 character set would cause "Specified key was too long; max key length is 1000 bytes" https://dev.mysql.com/doc/refman/5.6/en/innodb-fulltext-index.html * References "10.9.1 The utf8mb4 Character Set (4-Byte UTF-8 Unicode Encoding)" https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8mb4.html "10.9.2 The utf8mb3 Character Set (3-Byte UTF-8 Unicode Encoding)" https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8.html "14.8.1.7 Limits on InnoDB Tables" https://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html > If innodb_large_prefix is enabled (the default), the index key prefix limit is 3072 bytes > for InnoDB tables that use DYNAMIC or COMPRESSED row format. * CI against MySQL 5.7 Followed this instruction and changed root password to empty string. https://docs.travis-ci.com/user/database-setup/#MySQL-57 * The recommended minimum version of MySQL is 5.7.9 to support utf8mb4 character set and `innodb_default_row_format` MySQL 5.7.9 introduces `innodb_default_row_format` to support 3072 byte length index by default. Users do not have to change MySQL database configuration to support Rails string type. https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_default_row_format https://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html > If innodb_large_prefix is enabled (the default), > the index key prefix limit is 3072 bytes for InnoDB tables that use DYNAMIC or COMPRESSED row format. * The recommended minimum version of MariaDB is 10.2.2 MariaDB 10.2.2 is the first version of MariaDB supporting `innodb_default_row_format` Also MariaDB says "MySQL 5.7 is compatible with MariaDB 10.2". - innodb_default_row_format https://mariadb.com/kb/en/library/xtradbinnodb-server-system-variables/#innodb_default_row_format - "MariaDB versus MySQL - Compatibility" https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/ > MySQL 5.7 is compatible with MariaDB 10.2 - "Supported Character Sets and Collations" https://mariadb.com/kb/en/library/supported-character-sets-and-collations/
* | | | Don't expose `instantiate_instance_of` for internal useRyuta Kamizono2018-09-111-11/+7
| | | |
* | | | Refactor object creation from relation to avoid pushing scope attributesRyuta Kamizono2018-09-112-24/+7
| | | | | | | | | | | | | | | | | | | | | | | | Pushing scope attributes was added at d4007d5 for fixing inheritance object creation. But it was not a better fix, since we could just pull that on demand in `Inheritance` module.
* | | | Don't expose `current_scope` for internal useRyuta Kamizono2018-09-112-16/+15
| | | |
* | | | Move `scoping` handling into klass level from relationRyuta Kamizono2018-09-112-5/+9
| | | | | | | | | | | | | | | | | | | | I'd like to use this `scoping` handling on klass level to address unwanted internal scoping issues.
* | | | Remove redundant `all.scoping`Ryuta Kamizono2018-09-111-4/+2
| | | | | | | | | | | | | | | | | | | | `scoping` stashes the reciever and then returning that as `klass.all`. `all.scoping` has no effect to the public behavior, so it is redundant.
* | | | Fixes #33610Darwin D Wu2018-09-111-7/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to avoid double assignments of nested_attributes for `has_many` relations during record initialization, nested_attributes in `create_with` should not be passed into `klass.new` and have them populate during `initialize_internals_callback` with scope attributes. However, `create_with` keys should always have precedence over where clauses, so if there are same keys in both `create_with` and `where_values_hash`, the value in `create_with` should be the one that's used.
* | | | Merge pull request #33825 from bogdanvlviv/follow-up-33637-and-33770Eileen M. Uchitelle2018-09-092-6/+6
|\ \ \ \ | | | | | | | | | | Follow up #33637 and #33770
| * | | | Fix `ActiveRecord::DatabaseConfigurations`'s docsbogdanvlviv2018-09-092-6/+6
| | | | |
* | | | | Consistently use `visitor.compile`Ryuta Kamizono2018-09-091-3/+3
| | | | |
* | | | | Use `visitor.compile` instead of constructing by connection itselfRyuta Kamizono2018-09-093-7/+3
| | | | |
* | | | | `supports_xxx?` returns whether a feature is supported by the backendRyuta Kamizono2018-09-084-3/+7
|/ / / / | | | | | | | | | | | | Rather than a configuration on the connection.
* | | | Configuration item `config.filter_parameters` could also filter out ↵Zhang Kang2018-09-072-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sensitive value of database column when call `#inspect` * Why Some sensitive data will be exposed in log accidentally by calling `#inspect`, e.g. ```ruby @account = Account.find params[:id] payload = { account: @account } logger.info "payload will be #{ payload }" ``` All the information of `@account` will be exposed in log. * Solution Add a class attribute filter_attributes to specify which values of columns shouldn't be exposed. This attribute equals to `Rails.application.config.filter_parameters` by default. ```ruby Rails.application.config.filter_parameters += [:credit_card_number] Account.last.insepct # => #<Account id: 123, credit_card_number: [FILTERED] ...> ```
* | | | Merge pull request #33809 from fidalgo/improve-remove-column-documentationRichard Schneeman2018-09-061-0/+1
|\ \ \ \ | | | | | | | | | | [ci skip] Improve remove_column documentation
| * | | | [ci skip] Improve remove_column documentationPaulo Fidalgo2018-09-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since when we remove one column it will also remove the associated indexes, we must ensure this behaviour is properly documented. In this commit we add a line to the documentation mentioning this behaviour.
* | | | | Deprecate most methods which were never used in `DatabaseLimits`Ryuta Kamizono2018-09-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `DatabaseLimits` and those methods were introduced at 3809c80, but most methods were never used and never tested from the beginning (except `table_alias_length`, `index_name_length`, and `in_clause_length` (since 66c09372)). There is no reason to maintain unused those methods for about 8 years.
* | | | | Remove unused blockEileen Uchitelle2018-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This method used to take a block, but that's no longer the case so we can delete the block from the method signature.
* | | | | Merge pull request #33673 from ↵Ryuta Kamizono2018-09-031-5/+5
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | tgxworld/regression_setting_children_record_in_parent_before_save Fix regression setting children record in parent before_save callback.
| * | | | | Fix regression setting children record in parent before_save callback.Guo Xiang Tan2018-09-031-5/+5
| | | | | |
* | | | | | Remove unused splat args in `_create_record`Ryuta Kamizono2018-09-022-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `_create_record` is passed `attribute_names` only. ``` % git grep -n '_create_record(attribute_names' lib/active_record/attribute_methods/dirty.rb:173: def _create_record(attribute_names = attribute_names_for_partial_writes) lib/active_record/counter_cache.rb:162: def _create_record(attribute_names = self.attribute_names) lib/active_record/locking/optimistic.rb:64: def _create_record(attribute_names = self.attribute_names) lib/active_record/persistence.rb:738: def _create_record(attribute_names = self.attribute_names) ```
* | | | | | [ci skip] Change some comments to conform to the style used in other commentsSharang Dashputre2018-09-013-6/+6
| | | | | |
* | | | | | Merge pull request #33770 from eileencodes/multi-db-improvements-part-3Eileen M. Uchitelle2018-09-018-23/+62
|\ \ \ \ \ \ | |/ / / / / |/| | | | | Part 3: Multi-db Improvements, identifying replica configurations
| * | | | | Convert configs_for to kwargs, add include_replicasEileen Uchitelle2018-08-316-23/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Add replica? check to DatabaseConfigEileen Uchitelle2018-08-313-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Checks if the config has a "replica" key, if so the configuration is for a replica database. This is useful for excluding replicas from the configurations list when creating the rake tasks or running rake tasks. For example, we don't want to create the primary and primary_readonly. They're the same database.
| * | | | | Add config option for `replica`.Eileen Uchitelle2018-08-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the user to add `replica: true` to the database config to signify the connection should be treated as readonly. This will be useful so we can ignore structure dumps or migrations (or creating / deleting etc) the readonly connection for the databases. These are paired with a write database which is where the create/drop/migrate should be run. This allows us to ask the connection if it's for a replica readonly db or a primary write db.
* | | | | | Just delegate `update` with ids on a relation to `klass.update`Ryuta Kamizono2018-08-311-2/+6
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This restores an ability that `update` with ids on a relation which is described at https://github.com/rails/rails/issues/33470#issuecomment-411203013. I personally think that the `update` with two arguments on a relation is not a designed feature, since that is totally not using a relation state, and also is not documented. But removing any feature should not be suddenly happened in a stable version even if that is not documented.
* | | | | Merge pull request #33637 from eileencodes/ar-connection-management-refactoringEileen M. Uchitelle2018-08-3011-166/+376
|\ \ \ \ \ | | | | | | | | | | | | Refactor Active Record configurations
| * | | | | Refactors Active Record connection managementEileen Uchitelle2018-08-3011-166/+376
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #33759 from schneems/schneems/move-variable-out-of-loopRichard Schneeman2018-08-301-2/+2
|\ \ \ \ \ \ | | | | | | | | | | | | | | Do not recompute length
| * | | | | | Do not recompute lengthschneems2018-08-301-2/+2
| |/ / / / / | | | | | | | | | | | | | | | | | | We can get a speed gain by moving the length calculation and assignment out of the loop.
* | | | | | Refactor `attributes_for_{create,update}` to avoid an extra allocationRyuta Kamizono2018-08-312-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Use `delete_if` instead of `reject` to avoid an extra allocation.
* | | | | | Remove `attributes_with_values_for_{create,update}` for internal useRyuta Kamizono2018-08-302-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `attributes_with_values_for_update` is no longer used since ae2d36c, and `attributes_with_values_for_create` is internally used only one place.
* | | | | | Remove extra `& self.class.column_names` in `keys_for_partial_write`Ryuta Kamizono2018-08-301-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should be done only once in `Persistence` module. https://github.com/rails/rails/blob/c83e30da27eafde79164ecb376e8a28ccc8d841f/activerecord/lib/active_record/persistence.rb#L721 https://github.com/rails/rails/blob/c83e30da27eafde79164ecb376e8a28ccc8d841f/activerecord/lib/active_record/persistence.rb#L740
* | | | | | Merge pull request #33729 from kddeisz/plural-automatic-inverseRafael França2018-08-291-5/+15
|\ \ \ \ \ \ | |/ / / / / |/| | | | | Find inverse associations with plural names
| * | | | | Find inverse associations with plural namesKevin Deisz2018-08-271-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously ActiveRecord couldn't find inverse associations if they were plural, which is a pretty standard use case. This commit changes the behavior to first attempt to find the singular version, then attempt to find the plural version. That makes it work and find plural associations as in the example below: ``` class Post has_many :comments end class Comment belongs_to :post end ``` Previously the `:post` association reflection would only attempt to find a `comment` inverse, as opposed to both a `comment` and `comments` inverse.
* | | | | | 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]
* | | | | | | Merge pull request #33748 from eileencodes/fix-erb-loading-issue-with-db-yamlEileen M. Uchitelle2018-08-291-1/+1
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | Drop load_database_yaml and fix test
| * | | | | | 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>
* | | | | | | Merge pull request #33718 from kddeisz/permit-listMatthew Draper2018-08-294-13/+15
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | Finish converting whitelist and blacklist references
| * | | | | | Permit list usage cleanup and clearer documentationKevin Deisz2018-08-274-11/+13
| | | | | | |
| * | | | | | Convert remaining usage of whitelist and blacklistKevin Deisz2018-08-241-2/+2
| | | | | | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 19:46:36 +0000