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.
Related
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.
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!
I was trying to fix a bad migration. I reset my database a couple times and it's just causing further problems, namely that not all my migrations are even running now.
Below are all the migrations, the one that was broken is the one yet to be run. But when I try to do a rake db:migrate I get this error:
undefined method `to_sym' for
nil:NilClass/usr/local/lib/ruby/gems/2.2.0/gems/activerecord-4.2.1/lib/active_record/connection_adapters/abstract/schema_definitions.rb:258:in
`column'
This is an issue in itself but what is most confusing to me is that the migration to create the simulation table just isn't running. My scheme looks like this:
ActiveRecord::Schema.define(version: 20150806192507) do
create_table "users", force: :cascade do |t|
t.string "email", limit: 96, default: "", null: false
t.string "encrypted_password", limit: 60, default: "", null: false
t.datetime "created_at"
t.datetime "updated_at"
end
add_index "users", ["email"], name: "index_users_on_email", unique: true
end
Any suggestions as to:
The simulations table is not being created when I do a reset and re-migrate.
The final migration to remove the verdict column is failing.
These are the migrations I have:
1.
class DeviseCreateUsers < ActiveRecord::Migration
def change
create_table(:users) do |t|
## Database authenticatable
t.string :email, :null => false, :default => "", limit: 96
t.string :encrypted_password, :null => false, :default => "", limit: 60
t.timestamps
t.index :email, unique: true
end
end
end
2.
class CreateSimulations < ActiveRecord::Migration
def change
# Needs the hash column worked out before this is run
create_table :simulations do |t|
t.integer :x_size
t.integer :y_size
t.string :verdict
t.string :arrangement
end
add_reference :simulations, :user, index: true
end
end
3.
class AddOpinionToSimulation < ActiveRecord::Migration
def change
add_column :simulations, :opinion, :hash
end
end
Finally, this is the bad one I was trying to run that started these problems. I have deleted the file to stop it from attempting to be migrated:
class RemoveVerdictFromSimulations < ActiveRecord::Migration
def change
remove_column :simulations, :verdict
end
end
Any suggestions?
There is no table simulations in your schema. If if it's not there, then you'll never be able to run that third migration.
First, refresh your database schema to make sure it's accurate in relation to your database with rake db:schema:dump
If there is indeed no simulations table, then first make sure that migration 2 succeeds.
Check schema_migrations table. If there are two rows there, then rails will think that the simulations table got created already, just delete the last entry from this table and migrate again making sure that the simulations table gets created this time, then try again with migration 3
My solution to this particular error was to go into my SQL database, delete every single version in the schema table. Then I did a
rake db:drop
I then walked through each version to make sure they migrated in order using:
rake db:migrate VERSION=<VERSION_NUMBER_FROM_EARLIEST_TO_LATEST>
If I ran into an error about a table not existing using:
rake db:prepare
Seemed to fix it aside from the last problem migration.
I have a db with columns (name, path). Now I have a migration file that changes the columns to be (name, pathorig, pathjson, scramble).
Doing rake db:reset and rake db:migrate doesn't update the table. Why can this happen?
my migration file:
class CreateUploads < ActiveRecord::Migration
def change
create_table :uploads do |t|
t.string :name
t.string :pathorig
t.string :pathjson
t.string :scramble
t.timestamps
end
end
end
The schema.rb file:
ActiveRecord::Schema.define(version: 20131029072745) do
create_table "uploads", force: true do |t|
t.string "name"
t.string "path"
t.datetime "created_at"
t.datetime "updated_at"
end
end
Difference between rake db:migrate db:reset and db:schema:load has a great explanation of what the various rake db:* commands do.
Because rake db:reset performs a db:schema:load, it's loading the old columns from your table, rather than calling db:migrate, this is why your migration isn't being run.
Consider writing a migration that changes the names of those columns, rather than re-creates an existing table, or manually run rake db:drop; rake db:create 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".