| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you had a foreign key set and then decided to add `on_delete:
:cascade` later in another migration that migration would run but
wouldn't refresh the schema dump.
The reason for this was because `create_table_info` caches the statement
and sets it to be the same as the original declaration for the foreign
key (without the `on_delete: :cascade`.
PR #25307 ended up fixing this bug because it removes the check for
`create_table_info` and relies on reading from `information_schema`. The
fix however was intended to patch another bug. The reason this fixes the
issue is we're no longer parsing the regex from the cached
`create_table_info`.
This regression test is to ensure that the issue does not return if we
for some reason go back to using `create_table_info` to set the foreign
keys.
|
|
|
|
|
|
|
|
| |
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
|
|\
| |
| | |
create_join_table should work with uuid
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| | |
prathamesh-sonpatki/fix-showing-of-deprecation-warning-for-legacy-migrations
Correctly show deprecation warning for incompatible migrations
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Tests on Travis are randomly failing because schema_migrations table
does not exist in teardown block.
- Also checked that all other places where we have used
`ActiveRecord::SchemaMigration.delete_all` we have rescued it, so used
it here also. This failure was not specifically related to the test
added in this PR but to overall compatibility migration tests, so
adding as separate commit.
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
Let t.foreign_key use the same `to_table` twice
Conflicts:
activerecord/CHANGELOG.md
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if you used `t.foreign_key` twice within the same
`create_table` block using the same `to_table`, all statements except
the final one would fail silently. For example, the following code:
def change
create_table :flights do |t|
t.integer :from_id, index: true, null: false
t.integer :to_id, index: true, null: false
t.foreign_key :airports, column: :from_id
t.foreign_key :airports, column: :to_id
end
end
Would only create one foreign key, on the column `from_id`.
This commit allows multiple foreign keys to the same table to be created
within one `create_table` block.
|
|\
| |
| | |
Make to primary key instead of an unique index for internal tables
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
- Using `references` or `belongs_to` in migrations will always add index
for the referenced column by default, without adding `index:true` option
to generated migration file.
- Users can opt out of this by passing `index: false`.
- Legacy migrations won't be affected by this change. They will continue
to run as they were before.
- Fixes #18146
|
| |
|
|
|
|
|
|
|
| |
uuid-ossp extension is alreadly enabled on test schema.
And `disable_extension!('uuid-ossp', connection)` can be a cause of test failure.
`ActiveRecord::StatementInvalid: PG::UndefinedFunction: ERROR: function uuid_generate_v1() does not exist`
will happen depending on the execution order.
|
|
|
|
| |
Follow up to #22642.
|
|\
| |
| |
| | |
Ignore index name in `index_exists?` when not passed a name to check for
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
| |
Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.
Application code should *not* do this.
|
|
|
|
| |
`adapters/postgresql/geometric_test.rb`
|
|
|
|
|
|
|
|
|
|
| |
Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.
And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #21563.
The `name` argument of `add_references` was both used to generate the
column name `<name>_id` and as the target table for the foreign key
`name.pluralize`.
It's primary purpose is to define the column name. In cases where the
`to_table` of the foreign key is different than the column name we
should be able to specify it individually.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If foreign keys specified in create table, generated SQL is slightly more
efficient.
Definition:
```
create_table :testings do |t|
t.references :testing_parent, foreign_key: true
end
```
Before:
```
CREATE TABLE "testings" ("id" serial primary key, "testing_parent_id" integer);
ALTER TABLE "testings" ADD CONSTRAINT "fk_rails_a196c353b2" FOREIGN KEY ("testing_parent_id") REFERENCES "testing_parents" ("id");
```
After:
```
CREATE TABLE "testings" ("id" serial primary key, "testing_parent_id" integer, CONSTRAINT "fk_rails_a196c353b2" FOREIGN KEY ("testing_parent_id") REFERENCES "testing_parents" ("id"));
```
|
| |
|
| |
|
|\ |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
vngrs/foreign_key_with_table_name_suffix_and_prefix
Add table name prefix and suffix support for foreign keys
|
| | |
| | |
| | |
| | |
| | |
| | | |
remove_foreign_key methods
fix tests
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Passing `:from` and `:to` to `change_column_default` makes this command
reversible as user has defined its previous state.
So, instead of having the migration command as:
change_column_default(:posts, :state, "draft")
They can write it as:
change_column_default(:posts, :state, from: nil, to: "draft")
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This used to raise a `IrreversibleMigration` error (since #10437).
However since `remove_index :table, :column` is probably the most basic
use-case we should make it reversible again.
Conflicts:
activerecord/CHANGELOG.md
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
since NUMBER(8) is not enough to store the maximum number of bigint.
Oracle NUMBER(p,0) as handled as integer
because there is no dedicated integer sql data type exist in Oracle database.
Also NUMBER(p,s) precision can take up to 38. p means the number of digits, not the byte length.
bigint type needs 19 digits as follows.
$ irb
2.2.2 :001 > limit = 8
=> 8
2.2.2 :002 > maxvalue_of_bigint = 1 << ( limit * 8 - 1)
=> 9223372036854775808
2.2.2 :003 > puts maxvalue_of_bigint.to_s.length
19
=> nil
2.2.2 :004 >
|
|
|
|
|
|
|
|
|
|
| |
Add a test-case to make sure that `create_table` with
a `foreign_key: true` and an adapter without foreign key support
does not blow up.
Motivated by #19794.
Originating from: https://github.com/rails/rails/commit/99a6f9e60ea55924b44f894a16f8de0162cf2702#commitcomment-10855210
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
creating foreign key
test case for use singular table name if pluralize_table_names is setted as false while creating foreign key
refactor references foreign key addition tests
use singular table name while removing foreign key
merge foreign key singular table name methods
remove unnecessary drop table from test
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.
I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.
I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.
|
|
|
|
|
| |
We've replaced most querues using DROP TABLE in our tests already.
This patch replaces the last couple calls.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
Add `foreign_key_exists?` method.
|
| | |
|
| |
| |
| |
| |
| |
| | |
"active_support/testing/stream" is already required in `test_case.rb`.
Furthermore the test "test/cases/migration_test.rb" could no longer be executed
directly.
|
| | |
|