| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
|
| |
This makes more sense, as the foreign key ignore pattern is only used by
the schema dumper.
|
| |
|
|
|
|
|
| |
Some places we can't remove because Ruby still don't have a method
equivalent to strip_heredoc to be called in an already existent string.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`BigDecimal.new` has been deprecated in BigDecimal 1.3.3
which will be a default for Ruby 2.5.
Refer https://github.com/ruby/bigdecimal/commit/533737338db915b00dc7168c3602e4b462b23503
```
$ cd rails/activerecord/
$ git grep -l BigDecimal.new | grep \.rb | xargs sed -i -e "s/BigDecimal.new/BigDecimal/g"
```
- Changes made only to Active Record. Will apply the same change to
other module once this commit is merged.
- The following deprecation has not been addressed because it has been
reported at `ActiveRecord::Result.new`. `ActiveRecord::Result.ancestors`
did not show `BigDecimal`.
* Not addressed
```ruby
/path/to/rails/activerecord/lib/active_record/connection_adapters/mysql/database_statements.rb:34:
warning: BigDecimal.new is deprecated
```
* database_statements.rb:34
```ruby
ActiveRecord::Result.new(result.fields, result.to_a) if result
```
* ActiveRecord::Result.ancestors
```ruby
[ActiveRecord::Result,
Enumerable,
ActiveSupport::ToJsonWithActiveSupportEncoder,
Object,
Metaclass::ObjectMethods,
Mocha::ObjectMethods,
PP::ObjectMixin,
ActiveSupport::Dependencies::Loadable,
ActiveSupport::Tryable,
JSON::Ext::Generator::GeneratorMethods::Object,
Kernel,
BasicObject]
```
This commit has been tested with these Ruby and BigDecimal versions
- ruby 2.5 and bigdecimal 1.3.3
```
$ ruby -v
ruby 2.5.0dev (2017-12-14 trunk 61217) [x86_64-linux]
$ gem list |grep bigdecimal
bigdecimal (default: 1.3.3, default: 1.3.2)
```
- ruby 2.4 and bigdecimal 1.3.0
```
$ ruby -v
ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux-gnu]
$ gem list |grep bigdecimal
bigdecimal (default: 1.3.0)
```
- ruby 2.3 and bigdecimal 1.2.8
```
$ ruby -v
ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-linux]
$ gem list |grep -i bigdecimal
bigdecimal (1.2.8)
```
- ruby 2.2 and bigdecimal 1.2.6
```
$ ruby -v
ruby 2.2.8p477 (2017-09-14 revision 59906) [x86_64-linux]
$ gem list |grep bigdecimal
bigdecimal (1.2.6)
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If do not execute a type changing first, filling in default value may be
failed.
```
% ARCONN=postgresql be ruby -w -Itest test/cases/migration/compatibility_test.rb -n test_legacy_change_column_with_null_executes_update
Using postgresql
Run options: -n test_legacy_change_column_with_null_executes_update --seed 20459
E
Error:
ActiveRecord::Migration::CompatibilityTest#test_legacy_change_column_with_null_executes_update:
StandardError: An error has occurred, this and all later migrations canceled:
PG::StringDataRightTruncation: ERROR: value too long for type character varying(5)
: UPDATE "testings" SET "foo"='foobar' WHERE "foo" IS NULL
```
|
|
|
|
| |
`klass` has removed in 5358f2b67bd6fb12d708527a4a70dcab65513c5e.
|
|
|
|
|
|
|
| |
This test failed due to dirty schema cache. It is needed to call
`clear_cache!` when using same named table with different definition.
https://travis-ci.org/rails/rails/jobs/310627767#L769-L772
|
| |
|
|\
| |
| | |
Extract sql fragment generators from PostgreSQL adapter
|
| | |
|
|/
|
|
| |
Add validate_constraint and update naming
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Currently implicit legacy primary key is compatible, but adding explicit
legacy primary key is not compatible. It should also be fixed.
Fixes #30664.
|
|
|
|
| |
Closes #24190
|
| |
|
|\
| |
| | |
CI with the latest stable(GA) version of MariaDB 10.2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
when tested with MariaDB 10.2.8 or higher
Refer #30485
https://mariadb.com/kb/en/the-mariadb-library/alter-table/#drop-column-if-exists-col_name-cascaderestrict
> MariaDB starting with 10.2.8
> Dropping a column that is part of a multi-column UNIQUE constraint is not permitted.
|
|/
|
|
|
|
| |
type columns
Fixes #30496.
|
|
|
|
|
| |
* Test `test_unabstracted_database_dependent_types` for `PostgreSQLAdapter`
* Add `test_change_column_with_new_precision_and_scale` for `SQLite3Adapter`
* This test case and comment was lost at 28bb02a78fd47527bb7a208d01a4594bb212812c
|
| |
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|\
| |
| | |
Remove FK together with column in MySQL
|
| |
| |
| |
| |
| |
| |
| | |
Unlike with other databses, MySQL doesn't let you remove the column
if there's a FK on this column.
For better developer experience we want to remove the FK together with
the column.
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
Formerly, `rename_table` only renamed primary key index name if the
column's data type was sequential (serial, etc in PostgreSQL). The
problem with that is tables whose primary keys had other data types
(e.g. UUID) maintained the old primary key name. So for example,
if the `cats` table has a UUID primary key, and the table is renamed to
`felines`, the primary key index will still be called `cats_pkey`
instead of `felines_pkey`. This PR corrects it.
|
| |
|
|
|
|
|
|
| |
This is a regression due to #28282.
Fixes #29136.
|
|
|
|
|
|
| |
Also, explicitly apply the order: generate_subscripts is unlikely to
start returning values out of order, but we should still be clear about
what we want.
|
|
|
|
|
|
|
|
|
| |
Sharing `options` causes some unexpected behavior. If `limit: 2` is
specified, this means that 2 bytes integer for a reference id column and
2 chars string for a reference type column. Another example, if
`unsigned: true` is specified, this means that unsigned integer for a
reference id column, but a invalid option for a reference type column.
So `options` should not be shared with a reference type column.
|
|
|
|
|
|
|
|
| |
Follow up of #26266.
The default type of `primary_key` and `references` were changed to
`bigint` since #26266. But `create_join_table` column type is still
`integer`. It should respect `references` column type.
|
|
|
|
|
|
|
| |
`supports_migrations?` was added at 4160b518 to determine if schema
statements (`create_table`, `drop_table`, etc) are implemented in the
adapter. But all tested databases has been supported migrations since
a4fc93c3 at least.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently `change_column` cannot drop default if `null: false` is
specified at the same time. This change fixes the issue.
```ruby
# cannot drop default
change_column "tests", "contributor", :boolean, default: nil, null: false
# we need the following workaround currently
change_column "tests", "contributor", :boolean, null: false
change_column "tests", "contributor", :boolean, default: nil
```
Closes #26582
|
|\
| |
| |
| |
| | |
kamipo/fix_remove_reference_to_multiple_foreign_keys_in_the_same_table
Fix `remove_reference` to multiple foreign keys in the same table
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The native timestamp type in MySQL is different from datetime type.
Internal representation of the timestamp type is UNIX time, This means
that timestamp columns are affected by time zone.
```
> SET time_zone = '+00:00';
Query OK, 0 rows affected (0.00 sec)
> INSERT INTO time_with_zone(ts,dt) VALUES (NOW(),NOW());
Query OK, 1 row affected (0.02 sec)
> SELECT * FROM time_with_zone;
+---------------------+---------------------+
| ts | dt |
+---------------------+---------------------+
| 2016-02-07 22:11:44 | 2016-02-07 22:11:44 |
+---------------------+---------------------+
1 row in set (0.00 sec)
> SET time_zone = '-08:00';
Query OK, 0 rows affected (0.00 sec)
> SELECT * FROM time_with_zone;
+---------------------+---------------------+
| ts | dt |
+---------------------+---------------------+
| 2016-02-07 14:11:44 | 2016-02-07 22:11:44 |
+---------------------+---------------------+
1 row in set (0.00 sec)
```
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Oracle database itself does not have `bigint` SQL type, then it gets `ORA-00902: invalid datatype`.
It can be addressed by using ActiveRecord `bigint` type
because Oracle enhanced adapter recognizes ActiveRecord `bigint` type
and transfer it to its equivalent SQL type `NUMBER(19)`.
|
| | |
|
|/
|
|
|
|
| |
The `default` arg of `index_name_exists?` is only used the adapter does
not implemented `indexes`. But currently all adapters implemented
`indexes` (See #26688). Therefore the `default` arg is never used.
|