Document the migration "rules"

[Fryguy]

• Use say_with_time
• All data migrations must have specs

[lpichler]

• when you are working with the model in data migration, define the model in the migration
• when there is model defined in your migration and it has column type, set
  self.inheritance_column = :_type_disabled example

 class CloudNetwork < ActiveRecord::Base
    self.inheritance_column = :_type_disabled
  end

[Fryguy]

• Describe the "why" behind having the rule that we don't use default, null, foreign keys, etc.

[lpichler]

• don't mix data and structural migration to the one migration, create separate migrations

[Fryguy]

• Explain the pitfalls of deserializing columns that might have serialized objects in them. In particular, MiqExpression, which is common, and describe avoiding desrialization and using a LIKE query can be used instead.
• Describe the benefits of update_all
• Describe batching and when it's possible to use a reentrant migration for LARGE data migrations.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[lpichler]

@miq-bot remove_label stale

[Fryguy]

• We need a note about if remove_column appears in a PR, there needs to be a linked PR in other repos showing that those columns are no longer used.

• Might wants to describe the different "hats" needed to be worn for review.

  • DBA - review for database schema issues that could lead to performance/inefficiency problems, as well as index selection
  • Rails - review for Rails-invalid column names such as non-foreign-keys that end in _id or a type column that isn't being used for STI
  • ManageIQ - review for understanding where the new tables fits in the grand scheme and what use cases it is supporting. For providers, it's important to understand if the new tables and the naming of things fits into the single pane of glass, and how those new tables would be reused by other provider of the same provider type.

[Fryguy]

Migrations should not create new rows if rows didn't previously exist...that is, an empty database migrated should still be empty in the end, particularly for test reasons. Data migrations of existing data can transform into new rows if necessary.

[bdunne]

Be region-aware in data migrations. When a data migration runs in the global region, you probably only want to update records for your region (especially when the data migration is complicated). Updating records for other regions is a waste of time since the migration will be run in the remote region and it will push the changes up.

[lpichler]

Use ActiveRecord::Base for models in migrations.

Part of the advantage of ApplicationRecord is that we can leave AR::Base unmolested, which is exactly what migrations want: a plain ordinary AR object with no app-code-of-the-day surprises.

taken from
https://github.com/ManageIQ/manageiq/pull/7312/files#r56356275