aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/migration/compatibility.rb
Commit message (Collapse)AuthorAgeFilesLines
* Start Rails 5.2 developmentMatthew Draper2017-03-221-1/+4
|
* The `default` arg of `index_name_exists?` makes to optionalRyuta Kamizono2017-02-131-2/+2
| | | | | | 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-071-1/+35
| | | | | | | | 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/+6
| | | | | | | | | | | | | | | | | | | | | 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.
* Tweak bigint PK handlingMatthew Draper2017-01-181-2/+1
| | | | | | * Don't force PKs on tables that have explicitly opted out * All integer-like PKs are autoincrement unless they have an explicit default
* Fix UUID primary key with default nil in legacy migrationRyuta Kamizono2017-01-091-1/+1
| | | | | | UUID primary key with no default value feature (#10404, #18206) was lost in legacy migration caused by #25395 got merged. Restore the feature again in legacy migration.
* Raises when `ActiveRecord::Migration` is inherited directly.Rafael Mendonça França2016-12-291-41/+21
|
* Remove unnecessary `connection_name` variableRyuta Kamizono2016-12-061-2/+1
|
* Make pg adapter use bigserial for pk by defaultPavel Pravosud2016-12-051-1/+11
|
* For `PostgreSQL >= 9.4` use `gen_random_uuid()`Yaw Boakye2016-11-221-0/+8
| | | | | | | | | | Since 9.4, PostgreSQL recommends using `pgcrypto`'s `gen_random_uuid()` to generate version 4 UUIDs instead of the functions in the `uuid-ossp` extension. These changes uses the appropriate UUID function depending on the underlying PostgreSQL server's version, while maintaining `uuid_generate_v4()` in older migrations.
* Avoid to allow unused splat args for `t.timestamps` in `create_table`Ryuta Kamizono2016-08-141-2/+2
| | | | | | Unfortunately `t.timestamps` in `create_table` allows unused splat args. But the same one in `change_table` does not allow them. This commit fixes the inconsistent behavior.
* normalizes indentation and whitespace across the projectXavier Noria2016-08-061-12/+12
|
* applies new string literal convention in activerecord/libXavier Noria2016-08-061-1/+1
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Add migration compatibility class for Rails 5.1Rafael Mendonça França2016-05-101-1/+4
|
* Migrations: move version-finding responsibilityyui-knk2016-04-291-0/+10
| | | | | | | `ActiveRecord::Migration` needn't know about migration version compatibility lookup. Delegate it to the Compatibility module. Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
* Update compatibility.rbBogdan2016-03-261-1/+1
|
* Correctly show deprecation warning for incompatible migrationsPrathamesh Sonpatki2016-02-121-1/+1
|
* Intervene on change_table as well as create_tableMatthew Draper2016-01-301-0/+13
|
* Pare back default `index` option for the migration generatorPrathamesh Sonpatki2016-01-241-0/+12
| | | | | | | | | | - 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
* fix remove_index for postgresql when running legacy migrationsLachlan Sylvester2016-01-061-2/+3
|
* Support removing custom-names indexes when only specifying column namesGrey Baker2015-12-151-0/+25
|
* Ignore index name in `index_exists?` when not passed a name to check forGrey Baker2015-12-151-0/+11
|
* In 4.2 migrations, `timestamps` defaulted to `null: true`Matthew Draper2015-12-151-0/+24
| | | | | .. it also showed a deprecation warning, but we obviously needn't retain that.
* Add migration versioning via Migration subclassesMatthew Draper2015-12-151-0/+30