| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when user has no parent table access privileges
Refer https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-errors
>>
* Previously, the ER_NO_REFERENCED_ROW_2 and ER_ROW_IS_REFERENCED_2 error messages
for foreign key operations were displayed and revealed information about parent tables,
even when the user had no parent table access privileges. Error handling for this situation has been revised:
* If the user does have table-level privileges for all parent tables,
ER_NO_REFERENCED_ROW_2 and ER_ROW_IS_REFERENCED_2 are displayed, the same as before.
* If the user does not have table-level privileges for all parent tables,
more generic error messages are displayed instead (ER_NO_REFERENCED_ROW and ER_ROW_IS_REFERENCED).
<<
This pull request addresses these 3 failures:
```ruby
$ ARCONN=mysql2 bundle exec ruby -w -Itest test/cases/adapter_test.rb -n /foreign/
Using mysql2
Run options: -n /foreign/ --seed 14251
F
Failure:
ActiveRecord::AdapterForeignKeyTest#test_foreign_key_violations_are_translated_to_specific_exception_with_validate_false [test/cases/adapter_test.rb:348]:
[ActiveRecord::InvalidForeignKey] exception expected, not
Class: <ActiveRecord::StatementInvalid>
Message: <"Mysql2::Error: Cannot add or update a child row: a foreign key constraint fails: INSERT INTO `fk_test_has_fk` (`fk_id`) VALUES (1231231231)">
... snip ...
rails test test/cases/adapter_test.rb:343
F
Failure:
ActiveRecord::AdapterForeignKeyTest#test_foreign_key_violations_on_delete_are_translated_to_specific_exception [test/cases/adapter_test.rb:368]:
[ActiveRecord::InvalidForeignKey] exception expected, not
Class: <ActiveRecord::StatementInvalid>
Message: <"Mysql2::Error: Cannot delete or update a parent row: a foreign key constraint fails: DELETE FROM fk_test_has_pk WHERE pk_id = 1">
... snip ...
rails test test/cases/adapter_test.rb:365
F
Failure:
ActiveRecord::AdapterForeignKeyTest#test_foreign_key_violations_on_insert_are_translated_to_specific_exception [test/cases/adapter_test.rb:358]:
[ActiveRecord::InvalidForeignKey] exception expected, not
Class: <ActiveRecord::StatementInvalid>
Message: <"Mysql2::Error: Cannot add or update a child row: a foreign key constraint fails: INSERT INTO fk_test_has_fk (fk_id) VALUES (0)">
... snip ...
rails test test/cases/adapter_test.rb:357
Finished in 0.087370s, 34.3366 runs/s, 34.3366 assertions/s.
3 runs, 3 assertions, 3 failures, 0 errors, 0 skips
$
```
|
|
|
|
| |
Follow up #32146.
|
|
|
|
|
|
|
| |
I don't prefer to extract it for one adapter even though all adapters
also does.
Related to #34227.
|
|
|
|
|
|
|
|
|
| |
Will allow sub classes to override the protected
`#check_version` method hook if desired.
For example, this will be most helpful in sub classes that wish
to support lazy initialization because the version check can
be postponed until the connection is ready to be initialized.
|
| |
|
|\
| |
| |
| | |
index option added for change_table migrations
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In case if we want to add a column into the existing table
with index on it, we have to add column and index in two
seperate lines.
With this feature we don't need to write an extra line to
add index for column. We can just use `index` option.
Old behaviour in action:
```
change_table(:languages) do |t|
t.string :country_code
t.index: :country_code
end
```
New behaviour in action:
```
change_table(:languages) do |t|
t.string :country_code, index: true
end
```
Exactly same behaviour is already exist for `create_table` migrations.
|
|\ \
| | |
| | | |
Add `Style/RedundantFreeze` to remove redudant `.freeze`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since Rails 6.0 will support Ruby 2.4.1 or higher
`# frozen_string_literal: true` magic comment is enough to make string object frozen.
This magic comment is enabled by `Style/FrozenStringLiteralComment` cop.
* Exclude these files not to auto correct false positive `Regexp#freeze`
- 'actionpack/lib/action_dispatch/journey/router/utils.rb'
- 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb'
It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333
Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed.
* Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required
- 'actionpack/test/controller/test_case_test.rb'
- 'activemodel/test/cases/type/string_test.rb'
- 'activesupport/lib/active_support/core_ext/string/strip.rb'
- 'activesupport/test/core_ext/string_ext_test.rb'
- 'railties/test/generators/actions_test.rb'
|
|/ / |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
| |
|
|
|
|
|
| |
Since #33875, Rails dropped supporting MySQL 5.1 which does not support
utf8mb4. We no longer need to use legacy utf8 (utf8mb3) conservatively.
|
|
|
|
|
|
|
| |
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]
|
|\
| |
| | |
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.
|
|\ \
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | | |
Remove mysql2 gem version requirement "< 0.6.0"
|
| | | |
| | | |
| | | |
| | | | |
Suggested at https://github.com/rails/rails/pull/33876#issuecomment-421176221
|
|/ / /
| | |
| | |
| | |
| | | |
Follow up #33874.
Related #23393.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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/
|
| | |
|
| | |
|
| |
| |
| |
| | |
Rather than a configuration on the connection.
|
|\ \
| | |
| | | |
[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 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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Add documentation for `:collation` option
The table definition supports a `:collation` option for string and text columns, but this is not documented anywhere that I could find.
I'm not sure if the "If not specified" part is accurate. From [this PR](https://github.com/rails/rails/commit/1515c4d98da3f730ef971fa5a13cad828bd9bef4), it looks like it passes `nil` and lets the database handle the collation, but I'm happy to change it if I misread the code.
[ci skip]
* FIX remove whitespace
[Nate Pinsky + Rafael Mendonça França]
|
|\ \ \
| | | |
| | | | |
Prevent deadlocks when waiting for connection from pool.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
When a thread that had the load interlock but was blocked waiting to check a connection out of the connection pool but all of the threads using the available connections were blocked waiting to obtain the load interlock an `ActiveRecord::ConnectionTimeoutError` exception was be thrown by the thread waiting for the connection.
When waiting for the connection to check out we should allow loading to proceed to avoid this deadlock.
|
|\ \ \ \
| | | | |
| | | | | |
Omit BEGIN/COMMIT statements for empty transactions
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If a transaction is opened and closed without any queries being run, we
can safely omit the `BEGIN` and `COMMIT` statements, as they only exist
to modify the connection's behaviour inside the transaction. This
removes the overhead of those statements when saving a record with no
changes, which makes workarounds like `save if changed?` unnecessary.
This implementation buffers transactions inside the transaction manager
and materializes them the next time the connection is used. For this to
work, the adapter needs to guard all connection use with a call to
`materialize_transactions`. Because of this, adapters must opt in to get
this new behaviour by implementing `supports_lazy_transactions?`.
If `raw_connection` is used to get a reference to the underlying
database connection, the behaviour is disabled and transactions are
opened eagerly, as we can't know how the connection will be used.
However when the connection is checked back into the pool, we can assume
that the application won't use the reference again and reenable lazy
transactions. This prevents a single `raw_connection` call from
disabling lazy transactions for the lifetime of the connection.
|
| | | | |
| | | | |
| | | | |
| | | | | |
This was introduced at 24f6bf0d96b58f2b2ef6a886c93d35cf8ce4f293.
|
| | | | |
| | | | |
| | | | |
| | | | | |
https://github.com/rails/rails/issues/31190
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes #33520.
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
SQLite3 adapter `alter_table` method restores foreign keys
|
| |/ / / /
| | | | |
| | | | |
| | | | | |
Related to #33520
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- Move changelog entry of #33530 up in order to preserve the chronology
since we always add new entries on the top of a changelog file.
- Clarify the changelog entry
- Clarify the docs of remove_foreign_key
- Ensure reversible of `remove_foreign_key` with `:primary_key` and `:to_table`
options.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
33515 invert remove foreign key support "to_table"
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
remove_foreign_key supports
- remove_foreign_key :accounts, :branches
- remove_foreign_key :accounts, to_table: :branches
but the second one is not reversible.
This branch is to fix and allow second one to be reversible.
[Nikolay Epifanov, Rich Chen]
|