| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Since counter cache handles touch option too.
|
| |
|
| |
|
|\
| |
| | |
Raise an error when loading all fixtures from nil fixture_path
|
| |
| |
| |
| | |
[Gannon McGibbon + Max Albrecht]
|
|\ \
| | |
| | | |
If association is a hash-like object preloading fails
|
| | |
| | |
| | |
| | |
| | |
| | | |
If you pass a hash-like object to preload associations (for example ActionController::Parameters)
preloader will fail with the ArgumentError.
This change allows passing objects that may be converted to a Hash or String into a preloader
|
| |/
|/|
| |
| |
| |
| |
| | |
`association.increment_counters` and `association.decrement_counters`
works regardless of parent target is loaded or not.
Related 52e11e462f6114a4d12225c639c5f501f0ffec7a.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 376ffe0ea2e59dc51461122210729c05a10fb443.
Since 38fae1f, `association.increment_counters` is called without
inflated parent target if inverse_of is disabled.
In that case, that commit would cause extra queries to inflate parent.
|
|/
|
|
| |
Fixes #19550.
|
| |
|
|\
| |
| | |
Stringify database configurations
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initially, `TOP` was introduced to support `limit` for MSSQL database.
Unlike PostgreSQL/MySQL/SQLite, MSSQL does not have native `LIMIT`/`OFFSET` support.
The commit adding `TOP` is 1a246f71616cf246a75ef6cbdb56032e43d4e643.
However, it figured out that `TOP` implementation was weak and it's not sufficient
to also support `OFFSET`, then `TOP` was substituted with
`ROW_NUMBER()` subquery in be48ed3071fd6524d0145c4ad3faeb4aafe3eda3.
This is a well known trick in MSSQL -
https://stackoverflow.com/questions/2135418/equivalent-of-limit-and-offset-for-sql-server.
So now we don't need this `visit_Arel_Nodes_Top` at all.
It does nothing useful but also adds an extra space after `SELECT` when `LIMIT` is being
used for **any** database.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 commands
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Since #33875, Rails dropped supporting MySQL 5.1 which does not support
utf8mb4. We no longer need to use legacy utf8 (utf8mb3) conservatively.
|
|\ \
| | |
| | | |
Make a deep copy of the _default_attributes in column_defaults
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When column_defaults is called it calls `value` on each instance of
Attribute inside the _default_attributes set. Since value is memoized in
the Attribute instance and that Attribute instance is shared across all
instances of a model the next call to the default value will be memozied
not running the proc defined by the user.
Fixes #33031.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
Don't update counter cache unless the record is actually saved
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a 4th attempt to make counter cache transactional completely.
Past attempts: #9236, #14849, #23357.
All existing counter cache issues (increment/decrement twice, lost
increment) are caused due to updating counter cache on the outside of
the record saving transaction by assigning belongs_to record, even
though assigning that doesn't cause the record saving.
We have the `@_after_replace_counter_called` guard condition to mitigate
double increment/decrement issues, but we can't completely prevent that
inconsistency as long as updating counter cache on the outside of the
transaction, since saving the record is not always happened after that.
We already have handling counter cache after create/update/destroy,
https://github.com/rails/rails/blob/1b90f614b1b3d06b7f02a8b9ea6cd84f15d58643/activerecord/lib/active_record/counter_cache.rb#L162-L189
https://github.com/rails/rails/blob/1b90f614b1b3d06b7f02a8b9ea6cd84f15d58643/activerecord/lib/active_record/associations/builder/belongs_to.rb#L33-L59
so just removing assigning logic on the belongs_to association makes
counter cache transactional completely.
Closes #14849.
Closes #23357.
Closes #31493.
Closes #31494.
Closes #32372.
Closes #33113.
Closes #33117
Closes #33129.
Closes #33458.
|
|\ \ \ \
| |_|/ /
|/| | | |
Deprecate ActiveRecord::Result#to_hash in favor of #to_a
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
method returns an array of hashes, not a hash
e.g. Hash.try_convert(result) calls #to_hash and raises a TypeError
[Gannon McGibbon + Kevin Cheng]
|
| |/
|/|
| |
| |
| |
| | |
When you pass an empty array to find we know we shoudl return an empty
array but it is surprising that we are returning the original empty
array instead of a new one.
|
|/
|
|
|
|
|
|
|
| |
`topic` and `reply` belongs_to associations on `SillyReply` are defined
with the same `foreign_key` (`parent_id`) and `counter_cache`
(`replies_count`) columns.
This would cause unintentional side-effect (e.g. saving `SillyReply`
object would cause double increment `replies_count`), so it is better to
avoid that side-effect.
|
|
|
|
|
|
|
| |
block
`ActiveRecord::MigrationContext.new` just create an instance, doesn't
have any side-effect.
|
|\
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Follow up #33874.
Related #23393.
|
|/ |
|
|\
| |
| |
| | |
Allow subclasses to redefine autosave callbacks for associated records
|
| | |
|
|\ \
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- 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
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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/
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
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] ...>
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`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.
|