| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
active_support/rails.rb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR moves the `schema_migration` to `migration_context` so that we
can access the `schema_migration` per connection.
This does not change behavior of the SchemaMigration if you are using
one database. This also does not change behavior of any public APIs.
`Migrator` is private as is `MigrationContext` so we can change these as
needed.
We now need to pass a `schema_migration` to `Migrator` so that we can
run migrations on the right connection outside the context of a rake
task.
The bugs this fixes were discovered while debugging the issues around
the SchemaCache on initialization with multiple database. It was clear
that `get_all_versions` wouldn't work without these changes outside the
context of a rake task (because in the rake task we establish a
connection and change AR::Base.connection to the db we're running on).
Because the `SchemaCache` relies on the `SchemaMigration` information we
need to make sure we store it per-connection rather than on
ActiveRecord::Base.
[Eileen M. Uchitelle & Aaron Patterson]
|
|
|
|
| |
Otherwise `Model.table_exists?` returns the staled cache result.
|
|
|
|
|
|
|
|
| |
`create_table` and `t.column` have the same named options (e.g.
`:comment`, `:primary_key`), so it should be separated table options
from column options.
Related #36373.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Since d1a74c1e012ed96f7179e53b9190b7da0a369e11, Active Record requires
SQLite version 3.8.0 or greater, so savepoints and partial indexes are
always available.
That commit also added a runtime version check, so we can remove the
minimum version requirement from the internal adapter documentation.
|
| |
|
|
|
|
|
|
|
|
|
| |
We can revert migrations using `change_column_comment` or
`change_table_comment` at current master.
However, results are not what we expect: comments are remained in new
status.
This change tells previous comment to these methods in a way like
`change_column_default`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running this migration on mysql at current master fails
because `add_references_for_alter` is missing.
```
change_table :users, bulk: true do |t|
t.references :article
end
```
This is also true for postgresql adapter,
but its `bulk_alter_table` implementation can fallback in such case.
postgresql's implementation is desirable to prevent unknown failure like this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
options
When I've added new `:size` option in #35071, I've found that invalid
`:limit` and `:precision` raises `ActiveRecordError` unlike other
invalid options.
I think that is hard to distinguish argument errors and statement
invalid errors since the `StatementInvalid` is a subclass of the
`ActiveRecordError`.
https://github.com/rails/rails/blob/c9e4c848eeeb8999b778fa1ae52185ca5537fffe/activerecord/lib/active_record/errors.rb#L103
```ruby
begin
# execute any migration
rescue ActiveRecord::StatementInvalid
# statement invalid
rescue ActiveRecord::ActiveRecordError, ArgumentError
# `ActiveRecordError` except `StatementInvalid` is maybe an argument error
end
```
I'd say this is the inconsistency worth fixing.
Before:
```ruby
add_column :items, :attr1, :binary, size: 10 # => ArgumentError
add_column :items, :attr2, :decimal, scale: 10 # => ArgumentError
add_column :items, :attr3, :integer, limit: 10 # => ActiveRecordError
add_column :items, :attr4, :datetime, precision: 10 # => ActiveRecordError
```
After:
```ruby
add_column :items, :attr1, :binary, size: 10 # => ArgumentError
add_column :items, :attr2, :decimal, scale: 10 # => ArgumentError
add_column :items, :attr3, :integer, limit: 10 # => ArgumentError
add_column :items, :attr4, :datetime, precision: 10 # => ArgumentError
```
|
|
|
|
|
|
|
|
| |
* s/Postgres/PostgreSQL/
* s/MYSQL/MySQL/, s/Mysql/MySQL/
* s/Sqlite/SQLite/
Replaced all newly added them after 6089b31.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sample example ->
Before:
prathamesh@Prathameshs-MacBook-Pro-2 blog *$ rails server thin
DEPRECATION WARNING: Passing the Rack server name as a regular argument is deprecated
and will be removed in the next Rails version. Please, use the -u
option instead.
After:
prathamesh@Prathameshs-MacBook-Pro-2 squish_app *$ rails server thin
DEPRECATION WARNING: Passing the Rack server name as a regular argument is deprecated and will be removed in the next Rails version. Please, use the -u option instead.
|
|
|
|
|
|
|
| |
Foreign keys could be created to the same table.
So `remove_foreign_key :from_table, :to_table` is sometimes ambiguous.
This allows `remove_foreign_key` to remove the select one on the same
table with giving both `to_table` and `options`.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `conn.column_exists?("testings", "created_at", "datetime")`
returns false even if the table has the `created_at` column.
That reason is that `column.type` is a symbol but passed `type` is not
normalized to symbol unlike `column_name`, it is surprising behavior to
me.
I've improved that to normalize a value before comparison.
|
|
|
|
|
|
|
|
| |
directly
Since `migration_context` has `migrations_paths` itself and provides
methods which returning values from parsed migration files, so there is
no reason to use the `parse_migration_filename` low level API directly.
|
|
|
|
|
|
|
| |
`connection.assume_migrated_upto_version`
Since #31727, `migrations_paths` in `assume_migrated_upto_version` is no
longer used.
|
| |
|
|
|
|
| |
[fatkodima & Stefan Kanev]
|
|
|
|
| |
Follow up #32146.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|