| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
| |
Add mention that `config.filter_parameters` also filters out sensitive
values of database columns when call `#inspect` since #33756.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
`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/
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
I'd like to use this `scoping` handling on klass level to address
unwanted internal scoping issues.
|
|
|
|
|
| |
`scoping` stashes the reciever and then returning that as `klass.all`.
`all.scoping` has no effect to the public behavior, so it is redundant.
|
|
|
|
|
| |
The `existing` arg was added at 8bc0fce, but it is no longer used since
aac9da2.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Follow up #33637 and #33770
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
The writer was added during Arel refactoring to pass Active Record
tests at 7a29220.
That is no longer used since 846832a.
|
| | |
|
|/
|
|
| |
Rather than a configuration on the connection.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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] ...>
```
|
|\
| |
| | |
[ci skip] Improve remove_column documentation
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`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.
|
| |
| |
| |
| |
| | |
This method used to take a block, but that's no longer the case so we
can delete the block from the method signature.
|
|\ \
| | |
| | |
| | |
| | | |
tgxworld/regression_setting_children_record_in_parent_before_save
Fix regression setting children record in parent before_save callback.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`_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)
```
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Part 3: Multi-db Improvements, identifying replica configurations
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
Refactor Active Record configurations
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | | |
Do not recompute length
|
| |/ /
| | |
| | |
| | | |
We can get a speed gain by moving the length calculation and assignment out of the loop.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
eileencodes/add-migrations_paths_option-to-migration-generator
Add migrations_paths option to migration generator
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Adds an option to the migration generator to allow setting the
migrations paths for that migration. This is useful for applications
that use multiple databases and put migrations per database in their own
directories.
```
bin/rails g migration CreateHouses address:string --migrations-paths=db/kingston_migrate
invoke active_record
create db/kingston_migrate/20180830151055_create_houses.rb
```
|
| | |
| | |
| | |
| | | |
Use `delete_if` instead of `reject` to avoid an extra allocation.
|
| | |
| | |
| | |
| | |
| | | |
`attributes_with_values_for_update` is no longer used since ae2d36c, and
`attributes_with_values_for_create` is internally used only one place.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |/ /
|/| | |
Find inverse associations with plural names
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | | |
Prevent leaking of user's DB credentials on `rails db:create` failure
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 test
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
|\ \ \ \
| |/ / /
|/| | | |
Finish converting whitelist and blacklist references
|
| | | | |
|