Error When Run Migrations on Heroku, Postgresql with Rails 5

Error when run migrations on Heroku, PostgreSQL with Rails 5

It seems like database is not provided for your app, you need to add one:

heroku addons:create heroku-postgresql

You can verify the database was added to your application by running:

heroku config --app your_app_name

When running migrations on Heroku, I get PG::Error: ERROR: relation member1_id does not exist

You're calling foreigner's methods with the wrong arguments. The first argument is the referenced table name not the referencing column name. And since your column names don't nicely match the table names you'll need :column options as well. Something like this:

t.foreign_key :users, :column => :member1_id, :dependent => :delete

That assumes that :users is the table name that your :member1_id and :member2_id columns should be pointing at.

The error message:

relation "member1_id" does not exist

tells you that PostgreSQL is looking for a table called member1_id but can't find it.

Heroku run rails db:migrate showing PG::DuplicateColumn: ERROR: column created_at of relation blogs already exists

You could add add_timestamps(:blogs, {:null=>true}) unless column_exists?(:blogs, :created_at) && column_exists?(:blogs, :updated_at). It looks like someone deployed a migration to fix that before or something and now you're trying as well. With the conditional, it will only run the add_timestamps migration method if there are no created or updated at columns

UPDATE

In the migration add the conditional. With the conditional, it will only run that step if the timestamp columns don't exist. The issue is that you or someone on your team has run the migration on heroku before then possibly rolled back locally and then redployed. The db still has that change, hence the error you're receiving. So if you add the conditional, it will add the time stamp columns only if they already don't exist on that table

def change
        add_timestamps :blogs, null: true unless column_exists??(:blogs, :created_at) && column_exists?(:blogs, :updated_at)
        # backfill existing record with created_at and updated_at
        # values making clear that the records are faked
        long_ago = DateTime.new(2020, 12, 29)
        Blog.update_all(created_at: long_ago, updated_at: long_ago)
        # change not null constraints
        change_column_null :blogs, :created_at, false
        change_column_null :blogs, :updated_at, false
    end

Can't migrate from Rails App to Heroku

Add pg in gemfile

group :production do
   gem 'pg', '~> 0.21'
   gem 'rails_12factor'
end

#Terminal
>$ bundle install
>$ git add .
>$ git commit -m 'pg added'
>$ git push heroku master

Make sure Gemfile.lock updated and has pg.

Heroku rake db:migrate does not create tables (Rails 5)

rake db:migrate won't load the schema.rb file. It'll only run the migrations. If you want to load the schema then you can use rake db:schema:load.

You might also need to be careful if you reinstate your migrations to run again as the schema_migrations table probably has a record of all your migrations having run already. You'd need to clear that table too (delete the records - not drop the table) in order to indicate that your migrations should run again.

Rails Migration Error w/ Postgres when pushing to Heroku

From the fine manual:

[ALTER TABLE ... ALTER COLUMN ...]

The optional USING clause specifies how to compute the new column value from the old; if omitted, the default conversion is the same as an assignment cast from old data type to new. A USING clause must be provided if there is no implicit or assignment cast from old to new type.

There is no implicit conversion from varchar to int in PostgreSQL so it complains that column "number" cannot be cast to type integer and the ALTER TABLE fails. You need to tell PostgreSQL how to convert the old strings to numbers to match the new column type and that means that you need to get a USING clause into your ALTER TABLE. I don't know of any way to make Rails do that for you but you can do it by hand easily enough:

def up
  connection.execute(%q{
    alter table tweets
    alter column number
    type integer using cast(number as integer)
  })
end

You'll want to watch out for values that can't be cast to integers, PostgreSQL will let you know if there are problems and you'll have to fix them before the migration will succeed.

Your existing down-migration should be fine, converting integer to varchar should be handled automatically.

---

Related Topics