| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
[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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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]
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- 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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]
|
|/
|
|
| |
The consecutive verbatim blocks were being merged making the output look weird.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These OS versions have SQLite 3.8 or higher by default.
- macOS 10.10 (Yosemite) or higher
- Ubuntu 14.04 LTS or higher
Raising the minimum version of SQLite 3.8 introduces these changes:
- All of bundled adapters support `supports_multi_insert?`
- SQLite 3.8 always satisifies `supports_foreign_keys_in_create?` and `supports_partial_index?`
- sqlite adapter can support `alter_table` method for foreign key referenced tables by #32865
- Deprecated `supports_multi_insert?` method
|
|
|
|
|
| |
The merging order was accidentally changed at #32447. The original
intention is force `drop_table ... if_exists: true`. #28070.
|
|
|
|
| |
Ruby 2.6.0 warns about this.
|
|
|
|
|
|
|
| |
To solve the problem #32299, just enough to introduce
`fk_ignore_pattern` option.
I don't think there is a need to expose these constants.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dumping the database schema, Rails will dump foreign key names only
if those names were not generate by Rails. Currently this is determined
by checking if the foreign key name is `fk_rails_` followed by
a 10-character hash.
At [Cookpad](https://github.com/cookpad), we use
[Departure](https://github.com/departurerb/departure) (Percona's
pt-online-schema-change runner for ActiveRecord migrations) to run migrations.
Often, `pt-osc` will make a copy of a table in order to run a long migration
without blocking it. In this copy process, foreign keys are copied too,
but [their name is prefixed with an underscore to prevent name collision
](https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html#cmdoption-pt-online-schema-change-alter-foreign-keys-method).
In the process described above, we often end up with a development
database that contains foreign keys which name starts with `_fk_rails_`.
That name does not match the ignore pattern, so next time Rails dumps
the database schema (eg. when running `rake db:migrate`), our
`db/schema.rb` file ends up containing those unwanted foreign key names.
This also produces an unwanted git diff that we'd prefer not to commit.
In this PR, I'd like to suggest a way to expose the foreign key name
ignore pattern to the Rails configuration, so that individual projects
can decide on a different pattern of foreign keys that will not get
their names dumped in `schema.rb`.
|
| |
|
|
|
|
|
| |
MySQL supports descending indexes from 8.0.1 onwards:
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-1.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.
This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.
The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:
```
development:
adapter: mysql2
username: root
password:
development_seconddb:
adapter: mysql2
username: root
password:
migrations_paths: "db/second_db_migrate"
```
Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".
The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.
|
|
|
|
|
|
|
| |
`options_for_index_columns`
And placed `add_options_for_index_columns` in `schema_statements.rb`
consistently to ease to find related code.
|
| |
|
|\
| |
| | |
Extract sql fragment generators from PostgreSQL adapter
|
| | |
|
| |
| |
| |
| | |
Add validate_constraint and update naming
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Add support for specifying non-default operator classes in PostgreSQL
indexes. An example CREATE INDEX query that becomes possible is:
CREATE INDEX users_name ON users USING gist (name gist_trgm_ops);
Previously it was possible to specify the `gist` index but not the
custom operator class. The `add_index` call for the above query is:
add_index :users, :name, using: :gist, opclasses: {name: :gist_trgm_ops}
|
|
|
|
|
|
| |
Replace the primary key type `integer` in docs with `bigint`.
ref #26266
|
| |
|
|
|
|
| |
`initialize_internal_metadata_table`
|
| |
|
|
|
|
| |
This basically reverts 9d4f79d3d394edb74fa2192e5d9ad7b09ce50c6d
|
|
|
|
|
| |
Implemented by #22911
Related to #30677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I got this error in production using Puma in multi-threaded mode:
```
RuntimeError: Digest::Base cannot be directly inherited in Ruby
from active_support/security_utils.rb:23:in `variable_size_secure_compare'
from active_support/security_utils.rb:23:in `hexdigest'
from active_support/security_utils.rb:23:in `digest'
```
Looks like Digest uses const_missing to load Digest::SHA256 (https://github.com/ruby/ruby/blob/trunk/ext/digest/lib/digest.rb#L8)
- https://bugs.ruby-lang.org/issues/9494
- https://github.com/ruby/ruby/commit/c02fa39463a0c6bf698b01bc610135604aca2ff4
|
| |
|
|
|
|
| |
- Closes #30441
|
|
|
|
|
|
|
| |
Currently `SchemaDumper` is only customizable for column options. But
3rd party connection adapters (oracle-enhanced etc) need to customizable
for table or index dumping also. To make it possible, I introduced
adapter specific `SchemaDumper` classes for that.
|
| |
|
|
|
|
|
| |
The limit option is ignored by PostgreSQL and may be ignored by 3rd
party backends. Make this clear in the docs. Fixes #29922.
|
| |
|
|\ |
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |\
| | |
| | |
| | | |
Enforce frozen string in Rubocop
|
| | | |
|
| |\ \
| | | |
| | | |
| | | | |
Make ActiveSupport frozen-string-literal friendly.
|
| | |/ |
|
| |/
| |
| |
| |
| |
| | |
`test_middleware_caches` is sometimes failed since #29454.
The failure is due to schema statements are affected by query caching.
Bypassing query caching for schema statements to avoid the issue.
|
|/ |
|
|
|
|
| |
Fixes #29460.
|
|
|
|
| |
This option was added in b9fa354. But it does not seem to work.
|
| |
|
|\
| |
| |
| |
| | |
Nerian/document_support_for_composite_primary_keys
Document support for composite primary keys
|
| | |
|
|/
|
|
| |
present.
|