| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Fix deprecation warning of `ActiveRecord::Migrator.migrations_path=`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`ActiveRecord::Migrator.migrations_path=` was deprecated in #31727.
This commit fixes:
- `ActiveRecord::Migrator.migrations_path=` is deprecated, but not
`ActiveRecord::Migrator.migrations_paths=`
- Adds missing space
The warning including this commit:
```
DEPRECATION WARNING: `ActiveRecord::Migrator.migrations_path=` is now
deprecated and will be removed in Rails 6.0. You can set the `migrations_paths`
on the `connection` instead through the `database.yml`.
```
Since it was deprecated in Rails 5.2 we should backport it to the `5-2-stable` branch.
Related to #31727
|
|/
|
|
|
|
|
| |
block
`ActiveRecord::MigrationContext.new` just create an instance, doesn't
have any side-effect.
|
|\
| |
| | |
PostgreSQL: prepare for pg-1.1
|
| |
| |
| |
| |
| |
| |
| |
| | |
Parsing of malformed array strings without raising an error is deprecated in
pg-1.1. It's therefore necessary to catch parser errors starting with pg-2.0.
See also pg commit:
https://bitbucket.org/ged/ruby-pg/commits/1b081326b346368e70c9c03ee7080e28d6b3a3dc
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Version 1.1.0 deprecates exec and async_exec with a params array due to
distinct semantics between calls with and without params array.
Instead exec_params or async_exec_params shall be used.
Moreover in pg-1.1.0 exec_* and prepare methods are aliases for async_exec_*
and async_prepare. async_* methods don't need to be called explicit -
they are the default now, when calling exec_* and prepare.
For pg versions before 1.1, keep using async_exec.
|
|\ \
| | |
| | |
| | |
| | | |
faucct/bugfix/preload_multiple_instances_of_same_record
ActiveRecord::Associations::Preloader should preload all instances of the same record
|
| | |
| | |
| | |
| | | |
same record
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MySQL supports JOINs to UPDATE, so if column name isn't qualified by
table name, it would cause an ambiguous error:
```
Mysql2::Error: Column 'integer' in field list is ambiguous: UPDATE `pets` INNER JOIN `toys` ON `toys`.`pet_id` = `pets`.`pet_id` SET `integer` = COALESCE(`integer`, 0) + 1 WHERE `toys`.`name` = ?
```
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`relations_test.rb`
`persistence_test.rb` and `relations_test.rb` have too many lines, so
I'd like to extract relation around tests to dedicated files before
newly test added.
|
|\ \ \
| |/ /
|/| | |
Fallback to unprepared statement only when bind params limit is exceeded
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a follow up and/or an alternative of #33844.
Unlike #33844, this would attempt to construct unprepared statement only
when bind params limit (mysql2 65535, pg 65535, sqlite3 249999) is
exceeded.
I only defined 65535 as the limit, not defined 249999 for sqlite3, since
it is an edge case, I'm not excited to add less worth extra code.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Update association_basics.md [ci skip]
Addresses issue #33599
* Update associations.rb API documentation [ci skip]
Additional detail for documentation of `belongs_to` `association=(associate)`
* Update association_basics.md [ci skip]
Reverts misplaced documentation comment
|
|\ \ \
| | | |
| | | | |
Remove mysql2 gem version requirement "< 0.6.0"
|
| | | |
| | | |
| | | |
| | | | |
Suggested at https://github.com/rails/rails/pull/33876#issuecomment-421176221
|
|/ / /
| | |
| | |
| | |
| | | |
Follow up #33874.
Related #23393.
|
|/ / |
|
|\ \
| | |
| | | |
add `any?` to DatabaseConfigurations
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
Allow subclasses to redefine autosave callbacks for associated records
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | | |
Validate if `utf8mb4` character set and longer index key prefix is supported
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* MySQL 5.1 does not support `utf8mb4` character set
* MySQL 5.1 had been already EOLed on Dec 2013
https://www.mysql.com/support/eol-notice.html
> Per Oracle's Lifetime Support policy, as of December 31, 2013, MySQL 5.1
> is covered under Oracle Sustaining Support.
* MySQL 5.5.8 is the first General Availability of MySQL 5.5
https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-8.html
|
| | | |
| | | |
| | | |
| | | | |
are not supported
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| |/ / /
|/| | | |
Eager loading/preloading should be worked regardless of large number of records
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
CHANGELOG
Since #33770 `#configs_for` changed method signature and it isn't
supposed to work with a passed block.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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] ...>
```
|
| | |
| | |
| | |
| | | |
Fixing code block rendering, indentation, backticks, etc.
|