So.. im trying to migrate my db to heroku for the first time, doing:
heroku rake db:migrate
but im getting this horrible error that i cant resolve !
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
ActiveRecord::SchemaMigration Load (1.8ms) SELECT "schema_migrations".* FROM "schema_migrations"
Migrating to CreateComments (20150528110329)
(1.6ms) BEGIN
== 20150528110329 CreateComments: migrating ===================================
-- create_table(:comments)
(9.4ms) CREATE TABLE "comments" ("id" serial primary key, "name" character varying, "body" character varying, "post_id" integer, "created_at" timestamp NOT NULL, "updated_at" timestamp NOT NULL)
(3.8ms) CREATE INDEX "index_comments_on_post_id" ON "comments" ("post_id")
(6.4ms) ALTER TABLE "comments" ADD CONSTRAINT "fk_rails_2fd19c0db7"
FOREIGN KEY ("post_id")
REFERENCES "posts" ("id")
PG::UndefinedTable: ERROR: relation "posts" does not exist
: ALTER TABLE "comments" ADD CONSTRAINT "fk_rails_2fd19c0db7"
FOREIGN KEY ("post_id")
REFERENCES "posts" ("id")
(1.6ms) ROLLBACK
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
what i can understand is that its trying to reference from a table that doesnt exist yet.. but I dont know how to create my post table first...
schema.rb>
ActiveRecord::Schema.define(version: 20150622053408) do
create_table "comments", force: :cascade do |t|
t.string "name"
t.string "body"
t.integer "post_id"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
add_index "comments", ["post_id"], name: "index_comments_on_post_id"
create_table "posts", force: :cascade do |t|
t.string "title"
t.text "subtitle"
t.text "content"
t.string "img"
t.string "category"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
create_table "taggings", force: :cascade do |t|
t.integer "tag_id"
t.integer "taggable_id"
t.string "taggable_type"
t.integer "tagger_id"
t.string "tagger_type"
t.string "context", limit: 128
t.datetime "created_at"
end
add_index "taggings", ["tag_id", "taggable_id", "taggable_type", "context", "tagger_id", "tagger_type"], name: "taggings_idx", unique: true
add_index "taggings", ["taggable_id", "taggable_type", "context"], name: "index_taggings_on_taggable_id_and_taggable_type_and_context"
create_table "tags", force: :cascade do |t|
t.string "name"
t.integer "taggings_count", default: 0
end
add_index "tags", ["name"], name: "index_tags_on_name", unique: true
end
I tried switching in every way possible my code but with no results.
Hope that someone could help me out... thanks for everything!
I'm of the opinion that somewhere along the line one of your migrations were edited (which would be the problem if not properly rolledback first etc) and is now causing a major problem. And since you need to keep the data and can't do a full db:rollback I would say there is maybe one option I can think of unless someone else has a better idea. I never recommend editing migration files but I've had to do it in the past in certain circumstances. Do the following and make sure you keep in mind that any changes to the db can't be undone with a simple
git checkout .
I would create a new migration file by hand, not by using the rails generator and give it a timestamp that is a couple seconds before the timestamp of the Comments table migration file. I would then create the Posts table in that migration and edit the other existing migration that created the Posts table to just add it's columns. You must then go into your database (Not your rails console but your database which is probably Postgres) and insert this migration into the "schema_migrations" table. This schema_migrations table is automagically setup by rails whenever you generate a migration and run db:migrate. You'll notice the entries in this schema_migrations table are listed by "Version" where the version is the timestamp of the migration in your migration folder. You must then add the migration file timestamp to your schema_migrations table and it should be good to go.
UPDATE: IF you don't care about losing the data you can rollback all migrations, edit your migrations files and then re-run them.
bundle exec rake db:migrate:status #Look at the first version id and copy it.
bundle exec rake db:rollback VERSION=theVersionNumberYouCopiedHere
Then re check the migration statuses with the first command and make sure all migration statuses are listed as "down". This will have dropped all tables etc. Then go into your migration files and remove the referencing of your posts table from the Comments table that was giving you the issues. Then re-run all migrations again. Then add your posts_id reference to the comments table as follows by generating and running the following migration:
rails g migration AddPostToComments post:references
Looking in that migration file you should see something like this:
class AddPostToCommentss < ActiveRecord::Migration
def change
add_reference :comments, :post, index: true
add_foreign_key :comments, :posts
end
end
Now run bundle exec rake db:migrate and you should be good to go. Commit all the changes to git and then push to heroku!
Related
I am resolving a conflict on schema.rb by running rake db:migrate
The migration changing the definition
create_table "data_migrations", primary_key: "version", id: :string, force: :cascade do |t| end
To
create_table "data_migrations", force: :cascade do |t|
t.string "version", null: false
end
Are those 2 equivalent? Where does this change comes from?
Yes the above two definitions are same and they pertain to "schema_migrations" which version control and store the migration version history. They only have one column "version" which is string type and primary key for the table. They might have been modified when rake tasks related to schema load are run.
When I run rails db:migrate without a new migration it seems to have added two new tables: questions and questions_1.
In my schema file I see:
create_table "questions", id: false, force: :cascade do |t|
t.integer "id"
t.text "text"
t.boolean "active"
t.integer "organization_id"
t.datetime "created_at"
t.datetime "updated_at"
t.bigint "account_id"
t.bigint "team_id"
end
create_table "questions_1", id: false, force: :cascade do |t|
t.integer "id"
t.text "text"
t.boolean "active"
t.integer "organization_id"
t.datetime "created_at"
t.datetime "updated_at"
t.bigint "account_id"
t.bigint "team_id"
end
I don't have any migrations making these tables. I'm guessing this is some sort of convention. Where do I look to fix this? All recent changes are in the app/ directory and a migration I made has been rolled back and then deleted. Yet when I run rails db:migrate I always get these new tables.
Any ideas?
Rails won't create tables with any name other than the ones specified in a migration. If the table already exists then it will throw an error.
I believe someone has run a migration creating the second table on your database, and then deleted the migration. When rails creates your schema.rb file, it uses your database rather than any migrations, meaning this file reflects your actual database state rather than the one your migrations suggest would be the case.
If you're sure you don't want the second table and it has no data in it, then you can write out a new migration to delete this table, run it, and then delete it. This will return your database state to the one your migrations suggest would be the case. You can then run rake db:schema:dump to update your schema.
Can someone please help me with runing heroku run db:migrate? I've forgot to run db:migration on heroku along with migration on dev env. I made coulple of them and now I'm receiving the below error:
wozane:~/workspace (master) $ heroku run rake db:migrate
Running rake db:migrate on ⬢ wozane... up, run.7786
(0.8ms) SELECT pg_try_advisory_lock(96974639112725850);
ActiveRecord::SchemaMigration Load (1.1ms) SELECT "schema_migrations".* FROM "schema_migrations"
Migrating to RemoveColumnImage (20160917131520)
(0.7ms) BEGIN
== 20160917131520 RemoveColumnImage: migrating ================================
-- remove_column(:articles, :image_file_name, :string)
(1.5ms) ALTER TABLE "articles" DROP "image_file_name"
(0.7ms) ROLLBACK
(0.8ms) SELECT pg_advisory_unlock(96974639112725850)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PG::UndefinedColumn: ERROR: column "image_file_name" of relation "articles" does not exist
: ALTER TABLE "articles" DROP "image_file_name"
The case is that this column has been deleted and it doesn't exist.
Migration mentioned in the error message (number 20160917131520):
class RemoveColumnImage < ActiveRecord::Migration[5.0]
def change
remove_column :articles, :image_file_name , :string
remove_column :articles, :image_content_type, :string
remove_column :articles, :image_file_size, :integer
remove_column :articles, :image_updated_at, :datetime
end
end
Schema.rb looks like that:
ActiveRecord::Schema.define(version: 20160921115118) do
create_table "articles", force: :cascade do |t|
t.string "title"
t.text "text"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.string "img_url"
end
create_table "photos", force: :cascade do |t|
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.string "title"
t.string "img_url"
t.text "text"
end
end
I tried to #the whole code in migration and it didn't help along with those comments which did not work:
rails db:environment:set RAILS_ENV=production
heroku run rake db:reset
heroku run rake db:migrate -app wozane
heroku pg:reset DATABASE --confirm wozane
Does anyone have an idea how to run the heroku migration in my case?
Thanks in advance.
just comment out code of remove column migration.
class RemoveColumnImage < ActiveRecord::Migration[5.0]
def change
#remove_column :articles, :image_file_name , :string
#remove_column :articles, :image_content_type, :string
#remove_column :articles, :image_file_size, :integer
#remove_column :articles, :image_updated_at, :datetime
end
end
And try to run heroku run rake db:migrate -app wozane
I am in the process of installing devise. I followed all the required steps and ended here:
$ rails generate devise User
$ rake db:migrate
When I run rake db:migrate I get the following error:
$ rake db:migrate
== 20140618020442 AddDeviseToUsers: migrating =================================
-- change_table(:users)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
SQLite3::SQLException: duplicate column name: email: ALTER TABLE "users" ADD "em
ail" varchar(255) DEFAULT '' NOT NULLc:/appname/db/migrate/20140618020442_add_d
evise_to_users.rb:5:in `block in up'
c:/appname/db/migrate/20140618020442_add_devise_to_users.rb:3:in `up'
c:in `migrate'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
My project has the following database schema. Some of the devise migration appears to be successful, but the migration was not completed.
ActiveRecord::Schema.define(version: 20140618020442) do
create_table "listings", force: true do |t|
t.string "name"
t.text "description"
t.decimal "price"
t.datetime "created_at"
t.datetime "updated_at"
t.string "image_file_name"
t.string "image_content_type"
t.integer "image_file_size"
t.datetime "image_updated_at"
end
create_table "users", force: true do |t|
t.string "email", default: "", null: false
t.string "encrypted_password", default: "", null: false
t.string "reset_password_token"
t.datetime "reset_password_sent_at"
t.datetime "remember_created_at"
t.integer "sign_in_count", default: 0, null: false
t.datetime "current_sign_in_at"
t.datetime "last_sign_in_at"
t.string "current_sign_in_ip"
t.string "last_sign_in_ip"
t.datetime "created_at"
t.datetime "updated_at"
end
add_index "users", ["email"], name: "index_users_on_email", unique: true
add_index "users", ["reset_password_token"], name: "index_users_on_reset_password_token", unique: true
end
What is the problem and how do I fix it?
So the problem is you already have the users table inside your database. You need to either drop that table and create a new one if it's not working or just continue using that table.
It's not a good idea to drop your database but since you are making a new app(as you creating a users table) so in your case it'll be better to drop that database and recreate it(to make sure everything works). Try these commands in sequence:
rake db:drop
rake db:create
rake db:migrate
It should work fine and you need not do rails generate devise User as you already have your users migration file
Update:
If you don't want to drop your database then you can create a new migration file and delete your users table there.
rails generate migration DropUsersTable
after that edit your migration file
class DropUsersTable < ActiveRecord::Migration
def change
drop_table :users
end
end
and then do rake db:migrate
Solution:
1. Put all the migrations in migration folder in new archived_migrations folder.
2. db:schema:load
3. Run rake db:migrate
I have a sqlite3 db in a rails app with the following schema
ActiveRecord::Schema.define(:version => 20100816231714) do
create_table "comments", :force => true do |t|
t.string "commenter"
t.text "body"
t.integer "post_id"
t.datetime "created_at"
t.datetime "updated_at"
end
create_table "posts", :force => true do |t|
t.string "name"
t.string "title"
t.text "content"
t.datetime "created_at"
t.datetime "updated_at"
end
create_table "tags", :force => true do |t|
t.string "name"
t.integer "post_id"
t.datetime "created_at"
t.datetime "updated_at"
end
end
I began with a Post :has_many relationship with tags so each tag has a post_id reference.
I now want to change this relationship to a 'has_and_belongs_to_many', I know i have to create the joins table etc.... this isn't a problem and is working
The problem comes in when i try remove the post_id form the tags table. My migration looks like this:
class RemoveFieldsToTags < ActiveRecord::Migration
def self.up
remove_column :tags, :post_id
end
def self.down
add_column :tags, :post_id, :references
end
end
When I run rake db:migrate and rake db:migrate:up VERSION= Nothing happens when I run rake db:migrate:down VERSION= I get column:
SQLite3::SQLException: duplicate column name: post_id: ALTER TABLE "tags" ADD "post_id" references
Any one know whats going on?
It sounds as if Rails thinks your DB is up to date (given that nothing happens when you run db:migrate). You can get into this state if you've modified your migration after applying it (common during development).
Have you tried running db:migrate on a fresh db (note this will wipe your database)?
rake db:drop db:create db:migrate
Like avaynshtok mentions above, it sounds like rails thinks your migrations are up to date (as in, they have all been applied), but to you they are not (the post_id column is still on the tags table).
A common 'workaround' to deal with this situation without having to wipe your database is commenting out the 'down' method of your migration and running
rake db:migrate:redo
Given the 'down' is commented out, it won't try to add the column again, so it will proceed to reapply the 'up' method, removing your 'post_id' column. You can then remove the comment on the 'down' method and it should all be good.
PS. You might want to look into using a 'has_many :through' type of relationship instead of 'has_and_belongs_to_many' as well.
I had a similar problem to the op, but had to manually delete the databases and then run
rake db:create db:migrate
rake db:migrate:redo
and
rake db:drop
did not work for me as it kept saying "db/test.sqlite3 already exists".