Rails 6 - you can't define an already defined column

[KauanCS]

I'm trying to upgrade the rails 5.2 to 6.1. All migrations works fine on 5.2, but I started to receive this error on 6.1

Steps to reproduce

In my case, i'm using the postgres 9 but I tested in a new project with SQLite and has the same issue

• Create a new project with rails 6/7
• Create a new migration
• Add the code below:
• Run rails db:migrate

class Test < ActiveRecord::Migration[6.1]
  def change
    create_table :question_options, id: false do |t|
      t.string :label, null: false
    end

    create_table :answers, id: false do |t|
      t.string :question_option_id
    end

    create_join_table :question_options, :answers do |t|
      t.references :question_option, foreign_key: true, null: false, index: { name: :question_option_id}
      t.references :answer, foreign_key: true, null: false, index: {name: :answer_id}
    end
  end
end

Expected behavior

Run the migration without errors

Actual behavior

rails aborted!
StandardError: An error has occurred, this and all later migrations canceled:

you can't define an already defined column 'question_option_id'.

System configuration

Rails version: 6.1.7.1

Ruby version: 2.7.6

[fatkodima]

This is a new migration, generated when already using rails 6.1, correct (since it has ActiveRecord::Migration[6.1] in it)?

The syntax is incorrect, create_join_table already adds both columns referencing "joined" tables, see

rails/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb

Lines 374 to 386 in 444df0e

	def create_join_table(table_1, table_2, column_options: {}, **options)
	join_table_name = find_join_table_name(table_1, table_2, options)
	column_options.reverse_merge!(null: false, index: false)
	t1_ref, t2_ref = [table_1, table_2].map { |t| reference_name_for_table(t) }
	create_table(join_table_name, **options.merge!(id: false)) do |td|
	td.references t1_ref, **column_options
	td.references t2_ref, **column_options
	yield td if block_given?
	end
	end

You should use something like:

create_join_table :question_options, :answers, column_options: { foreign_key: true } # index is already added by `references`

[KauanCS]

Hey @fatkodima , thanks for your fast answer

This is a new migration, generated when already using rails 6.1, correct (since it has ActiveRecord::Migration[6.1] in it)?

A: I created this migration in rails 6.1 but I copied and paste the migration content from version 5.2

You should use something like:
create_join_table :question_options, :answers, column_options: { foreign_key: true } # index is already added by `references

A: It worked! But I have more than 300 migrations in project, do I need to update all of them with this new sintaxe in order to update to rails 6.1?

[skipkayhil]

A: I created this migration in rails 6.1 but I copied and paste the migration content from version 5.2

I believe a migration that worked as ActiveRecord::Migration[5.2] in 5.2 should work the same in all future versions of Rails (as long as you don't change the 5.2). Can you confirm what the original working migration version is?

A: It worked! But I have more than 300 migrations in project, do I need to update all of them with this new sintaxe in order to update to rails 6.1?

Since 6.1 isn't receiving bug fixes any more, there are probably a few options

• if we confirm there's a bug and fix it in time for next 7.0, then you could upgrade to 6.1 and then 7.0
• if you definitely need to run these old migrations on 6.1 then you may have to change them (although for the most part once a migration is run you don't necessarily have to run it ever again. You can db:schema:load a fresh database)

[KauanCS]

I believe a migration that worked as ActiveRecord::Migration[5.2] in 5.2 should work the same in all future versions of Rails (as long as you don't change the 5.2). Can you confirm what the original working migration version is?

In the original file is ActiveRecord::Migration[5.2] and running with rails 5.2.2 and works fine. But when I update the rails to 6.1.7.1 causes the issue.

Since 6.1 isn't receiving bug fixes any more, there are probably a few options

• if we confirm there's a bug and fix it in time for next 7.0, then you could upgrade to 6.1 and then 7.0
• if you definitely need to run these old migrations on 6.1 then you may have to change them (although for the most part once a migration is run you don't necessarily have to run it ever again. You can db:schema:load a fresh database)

I need to run these migrations to build my environment for tests e2e, the old migrations doesn't need to run on ActiveRecord::Migration[6.1] but should works with rails 6.1. Also, when I updated to 7.0, the issue persists (the old migrations doesn't run)

[fatkodima]

Confirmed locally that behavior (rails 5.2 migration do not work on newer rails). Will dive in.

In the meantime, do you really need to keep that history of migration files? You can rollup all of them into something like "initial migration" (just copy existing schema.rb file contents into the newly generated migration and delete previous ones). Or use db:schema:load for testing, as previously suggested. That should be faster than loading 300 files.

[KauanCS]

@fatkodima I notice that the issue is happening only in 4 migrations here. I think I can fix those to run on 6.1

It's a similar case and I believe the syntax is wrong, but I don't know where.

    create_table :tags, id: :uuid do |t|
      t.string :name, null: false
      t.uuid :created_by_id, null: false
      t.references :created_by, foreign_key: { to_table: :users }, type: :uuid, index: true, unique: false

      t.timestamps
    end

ArgumentError: you can't define an already defined column 'created_by_id'.

What is the correct use for references with create_table in rails 6?

[fatkodima]

I think t.uuid :created_by_id, null: false is not needed.

[fatkodima]

@KauanCS Can you verify that #47948 fixes your problem?

[skipkayhil]

@KauanCS the fix was merged, you should be able to point your Gemfile at 6-1-stable and the migrations should work without additional changes

[KauanCS]

@skipkayhil @fatkodima Thank you so much for your fast work!
The migrations are working now!