CODEWITHSUNDEEP
ruby-on-railspostgresqlheroku
bo-oz
bo-oz

Reputation: 2872

Running db:migrate causes some 'validations' on production, can that be turned off?

I'm pushing a working app (developed it locally) to a Heroku environment. When trying to run db:migrate on the production environment, the migrations fail because the postgreSQL seems to be doing some sanity checks that my sqlite on localhost wasn't doing, for instance:

Is there a way to fix the second error or is there a general way to prevent rails from the sanity checks (does the related table exist)?

EDIT:

Ok, so the relevant migration is this one:

class CreateQuestions < ActiveRecord::Migration
  def change
    create_table :questions do |t|
      t.string :title
      t.references :exercise, index: true, foreign_key: true
      t.text :content

      t.timestamps null: false
    end
  end
end

The problem with this is that there's no table exercises, because that one is named steps. So the referential integrity is breached for PostgreSQL resulting in the following error:

== 20151208132820 CreateQuestions: migrating ==================================
-- create_table(:questions)
   (14.1ms)  CREATE TABLE "questions" ("id" serial primary key, "title" character varying, "exercise_id" integer, "content" text, "created_at" timestamp NOT NULL, "updated_at" timestamp NOT NULL)
   (5.2ms)  CREATE  INDEX  "index_questions_on_exercise_id" ON "questions"  ("exercise_id")
   (9.3ms)  ALTER TABLE "questions" ADD CONSTRAINT "fk_rails_5ba13b3a6e"
FOREIGN KEY ("exercise_id")
  REFERENCES "exercises" ("id")

PG::UndefinedTable: ERROR:  relation "exercises" does not exist
: ALTER TABLE "questions" ADD CONSTRAINT "fk_rails_5ba13b3a6e"
FOREIGN KEY ("exercise_id")
  REFERENCES "exercises" ("id")

Upvotes: 0

Views: 59

Answers (2)

Ben Toogood
Ben Toogood

Reputation: 479

The foreign key constraint isn't needed. I would always recommend using the same database on your localhost as you will on your production server.

Remove the foreign key, deploy and the migration will work :)

Upvotes: 1

mtkcs
mtkcs

Reputation: 1716

I do think that the problem is coming from the foreign_key constraint, you can just remove it and check again.

A better solution is to mimic the production environment locally and make it work before pushing up.

Upvotes: 0

Related Questions