ruby-on-railsmariadbrails-migrations

Schema options being changed after migration


When I run the following migration file in rails:

class CreateSearchLogs < ActiveRecord::Migration[5.2]
  def change
    create_table :search_logs do |t|
      t.timestamp :created_at
      t.string :query
      t.integer :results_count
      t.string :first_5_results
      t.string :first_result_url
    end
  end
end

This option "COLLATE=utf8mb4_general_ci" is being added to the options of a number of tables in the schema. For example in the following table:

# schema.rb
create_table "suppliers", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC", force: :cascade do |t|

is being updated to

# schema.rb
create_table "suppliers", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci ROW_FORMAT=DYNAMIC", force: :cascade do |t|

This is locally. I have tried various different migrations without much success.

How can I run the migration without these additional changes?


Solution

  • Here is what's going on:

    When you run a migration, rails then does db:schema:dump. This recreates your schema file from the current database image. It will include various options depending on which database you are using at the moment. I'm not sure if there is any way to turn those off - I don't see any.

    The goal of these options is to make any new database created by the schema as close as possible to what you now have. But keep in mind they are options. If someone uses the same database type as you then you want them there. If someone uses a different kind of database then it will ignore any of those options it can't use.

    If you are concerned that these options will affect an existing database - they won't. Running migrations are what affect that.

    If you are concerned that the schema options are different because you think they should not be (ie. production/existing schema and database exist) then it is likely that your database options/configuration do not match those in production. You may want to change your local database configuration to closer match those in production.

    Mostly, though, you probably just should not worry about it.