aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/migration
Commit message (Collapse)AuthorAgeFilesLines
* Use assert_predicate and assert_not_predicateDaniel Colson2018-01-255-25/+25
|
* Change refute to assert_notDaniel Colson2018-01-252-7/+7
|
* Use respond_to test helpersDaniel Colson2018-01-251-2/+2
|
* Refactor migration to move migrations paths to connectioneileencodes2018-01-181-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* SQLite: Add more test cases for adding primary keyRyuta Kamizono2017-12-261-58/+48
|
* Fix `add_column` with :primary_key type compatibility for SQLitefatkodima2017-12-251-0/+19
|
* Suppress `warning: BigDecimal.new is deprecated` in activerecordYasuo Honda2017-12-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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) ```
* `change_column_default` should be executed after type changingRyuta Kamizono2017-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | 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 ```
* Fix `s/klass.connection/connection/`Ryuta Kamizono2017-12-031-1/+1
| | | | `klass` has removed in 5358f2b67bd6fb12d708527a4a70dcab65513c5e.
* Fix `test_add_column_with_timestamp_type` failureRyuta Kamizono2017-12-032-7/+8
| | | | | | | 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
* Fix warning: assigned but unused variable - tRyuta Kamizono2017-12-031-1/+1
|
* Merge pull request #31230 from dinahshi/postgresql_extract_sqlMatthew Draper2017-12-031-0/+17
|\ | | | | Extract sql fragment generators from PostgreSQL adapter
| * Extract sql fragment generators for alter table from PostgreSQL adapterDinah Shi2017-12-021-0/+17
| |
* | Add support for invalid foreign keys in PostgresTravis Hunter2017-12-011-0/+68
|/ | | | Add validate_constraint and update naming
* Remove deprecated argument `default` from `index_name_exists?`Rafael Mendonça França2017-10-231-4/+2
|
* Should test `LegacyPrimaryKeyTest` to both `V5_0` and `V4_2`Ryuta Kamizono2017-10-181-15/+34
|
* compatibility - use int instead of bigintpavel2017-10-181-0/+3
|
* Adding legacy primary key should be compatibleRyuta Kamizono2017-09-231-0/+51
| | | | | | | Currently implicit legacy primary key is compatible, but adding explicit legacy primary key is not compatible. It should also be fixed. Fixes #30664.
* Use algorithm while removing index with db:rollbackMehmet Emin İNAÇ2017-09-211-0/+5
| | | | Closes #24190
* make create_join_table compatible.Yuki Masutomi2017-09-201-0/+30
|
* Merge pull request #29850 from yahonda/test_with_mariadb_102_on_trustyRyuta Kamizono2017-09-011-0/+4
|\ | | | | CI with the latest stable(GA) version of MariaDB 10.2
| * Skip `test_remove_column_with_multi_column_index`Yasuo Honda2017-09-011-0/+4
| | | | | | | | | | | | | | | | | | | | 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.
* | `add_reference` should respect column position for both reference id and ↵Ryuta Kamizono2017-09-011-0/+10
|/ | | | | | type columns Fixes #30496.
* Improve `migration/column_attributes_test.rb` (#25286)Ryuta Kamizono2017-08-181-3/+17
| | | | | * 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
* Fix `test_add_column_with_timestamp_type` when using OracleKoichi ITO2017-07-251-0/+2
|
* Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-1917-0/+34
|
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-0217-17/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-0117-0/+17
|
* Merge pull request #29455 from kirs/remove-column-with-fk-mysqlGuillermo Iguaran2017-06-161-0/+10
|\ | | | | Remove FK together with column in MySQL
| * Remove FK together with column in MySQLKir Shatrov2017-06-161-0/+10
| | | | | | | | | | | | | | 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.
* | Add test for backward compatibility when using change_tableKoichi ITO2017-06-131-0/+15
|/
* `rename_table` renames primary key index nameYaw Boakye2017-05-291-0/+23
| | | | | | | | | | 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.
* Remove a redundant test case of command_recorder_testKoichi ITO2017-05-291-5/+0
|
* Both reference id and type should be `NOT NULL` if `null: false` is specifiedRyuta Kamizono2017-05-191-0/+8
| | | | | | This is a regression due to #28282. Fixes #29136.
* Use a query that's compatible with PostgreSQL 9.2Matthew Draper2017-04-121-1/+1
| | | | | | 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.
* Don't share `options` with a reference type columnRyuta Kamizono2017-03-041-0/+7
| | | | | | | | | 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.
* `create_join_table` should respect `references` column typeRyuta Kamizono2017-02-281-1/+12
| | | | | | | | 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.
* Deprecate `supports_migrations?` on connection adaptersRyuta Kamizono2017-02-271-12/+0
| | | | | | | `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.
* Fix `change_column` to drop default with `null: false`Ryuta Kamizono2017-02-261-0/+10
| | | | | | | | | | | | | | | | 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
* Merge pull request #25285 from ↵Rafael França2017-02-231-0/+16
|\ | | | | | | | | kamipo/fix_remove_reference_to_multiple_foreign_keys_in_the_same_table Fix `remove_reference` to multiple foreign keys in the same table
| * Fix `remove_reference` to multiple foreign keys in the same tableRyuta Kamizono2017-02-111-0/+16
| |
* | Correctly dump native timestamp types for MySQLRyuta Kamizono2017-02-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) ```
* | Remove unused DdlHelper in ForeignKeyTestRyuta Kamizono2017-02-141-2/+0
| |
* | Use ActiveRecord `bigint` type, not SQL literal bigintYasuo Honda2017-02-141-11/+14
| | | | | | | | | | | | | | | | 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)`.
* | Deprecate passing `default` to `index_name_exists?`Ryuta Kamizono2017-02-131-2/+4
| |
* | The `default` arg of `index_name_exists?` makes to optionalRyuta Kamizono2017-02-131-8/+6
|/ | | | | | 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.
* `primary_key` and `references` columns should be identical typeRyuta Kamizono2017-02-073-14/+13
| | | | | | | | Follow up to #26266. The default type of `primary_key` and `references` were changed to `bigint` since #26266. But legacy migration and sqlite3 adapter should keep its previous behavior.
* Restore the behaviour of the compatibility layer for integer-like PKsRyuta Kamizono2017-02-041-0/+104
| | | | | | | | | | | | | | | | | | | | | The PR #27384 changed migration compatibility behaviour. ```ruby class CreateMasterData < ActiveRecord::Migration[5.0] def change create_table :master_data, id: :integer do |t| t.string :name end end end ``` Previously this migration created non-autoincremental primary key expected. But after the PR, the primary key changed to autoincremental, it is unexpected. This change restores the behaviour of the compatibility layer.
* Virtual/generated column support for MySQL 5.7.5+ and MariaDB 5.2.0+Ryuta Kamizono2017-02-011-6/+1
| | | | | | | | | | | | | | | | | | | MySQL generated columns: https://dev.mysql.com/doc/refman/5.7/en/create-table-generated-columns.html MariaDB virtual columns: https://mariadb.com/kb/en/mariadb/virtual-computed-columns/ Declare virtual columns with `t.virtual name, type: …, as: "expression"`. Pass `stored: true` to persist the generated value (false by default). Example: create_table :generated_columns do |t| t.string :name t.virtual :upper_name, type: :string, as: "UPPER(name)" t.virtual :name_length, type: :integer, as: "LENGTH(name)", stored: true t.index :name_length # May be indexed, too! end Closes #22589
* show correct class name in migration inherited directly erroryuuji.yaginuma2017-01-241-2/+3
| | | | Follow up to 249f71a
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-03 00:11:49 +0000