Here is my model migration
class CreateSwimmingClassschedules < ActiveRecord::Migration
def change
create_table :swimming_classschedules do |t|
t.integer :slot_id
t.integer :coach_id
t.integer :level_id , :default => 1
t.string :note
t.timestamps
end
end
end
I expect after I call
Swimming::Classchedule.create(:coach_id=>8)
It will generate a default level_id in table. But somehow it didn't work. I'm in the dev environment using SQLite.
I added
:default => 1
after I ran
rake db:migrate
Does it matter?
Something I am missing?
Adding that line after you have run your migrations will not make the change.
Your syntax is correct but you will need to run a migration with that addition. Consider making a separate migration file like this:
class ChangeLevelId < ActiveRecord::Migration
def change
change_column :swimming_classschedules, :level_id, :integer, :default => 1
end
end
If you added :default => 1 AFTER you did a rake db:migrate, you will need to do a rake db:rollback and do a remigration of your database. That should do the trick.
Is it Classchedule or Classschedule ?
When I have a problem with my database, I recreate it :
rake db:drop
rake db:create
rake db:migrate
Related
I'm trying to deploy a simple Rails app in heroku but I'm getting this message in the heroku logs: PG::UndefinedTable: ERROR: relation "entries" does not exist
My migration file is like this:
class CreateEntries < ActiveRecord::Migration[6.0]
def change
create_table :entries do |t|
t.string :meal_type
t.integer :calories
t.integer :proteins
t.integer :carbs
t.integer :fats
t.timestamps
end
end
end
I've tried a few thing(including changing the name of the migration file manuallly) but don't know what to do.
terminal
Did you run the migrations in heroku? if not then you can do it like this:
heroku run rake db:migrate --app=your_app_name
Probably you don't have an 'entries' column on your DB
I am currently developing an Rails 4 app and over the last few months I collected a lot of unique migration files, which reverse their own changes, etc.
Since I have no problem to reset the db at this stage of development, I thought I could might clean up this mess a bit.Is there a way of redoing all migration files, while also allowing to delete certain migration-files and to expand others?
I appreciate each answer!
Example (Edit)
I have two migration files:
20160911071103_create_items.rb
20160918085621_add_cached_votes_to_items.rb
Both are already migrated.<
1st file before
class CreateItems < ActiveRecord::Migration
def change
create_table :items do |t|
t.integer :user_id
t.timestamps null: false
end
end
end
My goal is to include the added column by the second file directly in the first file and deleting the second.
1st file after
class CreateItems < ActiveRecord::Migration
def change
create_table :items do |t|
t.integer :user_id
t.integer :cached_votes
t.timestamps null: false
end
end
end
You need to run
rake db:migrate:down VERSION=20160918085621
rake db:migrate:down VERSION=20160911071103
You can now check the migration status by rake db:migrate:status and you should expect to get migration status as follows:
down 20160911071103
down 20160918085621
Now, you can remove the migration file 20160918085621_add_cached_votes_to_items.rb
& edit the migration file 20160911071103_create_items.rb as you need.
And, finally run:
rake db:migrate:up VERSION=20160911071103
As you are saying you it's on development only so you can change the migration files.
NOTE: It is not recommended to edit your migration but as it's not deployed anywhere so you can do it.
20160911071103_create_items.rb
class CreateItems < ActiveRecord::Migration
def change
create_table :items do |t|
t.integer :user_id
t.timestamps null: false
end
end
end
20160918085621_add_cached_votes_to_items.rb
class AddCachedVotesToItems < ActiveRecord::Migration
def change
add_column :items, :cached_votes, :integer
end
end
Modify your first migration and remember to delete second migration.
20160911071103_create_items.rb (Migration 1 + Migration 2)
class CreateItems < ActiveRecord::Migration
def change
create_table :items do |t|
t.integer :user_id
t.integer :cached_votes
t.timestamps null: false
end
end
end
And then Drop and Migrate again
rake db:drop # Drop the db
rake db:setup # Create and migrate the db
if you have a working schema.rb file. you can just generate a migration file
bundle exec rails generate migration CreateItemsNew
Then fill the codeblock create_table "items" from your working schema.rb to this newly generated migration file. Then do a bulk search for all the migrations in your db/migrate that changes the table items and delete those files. This way you'll have a single migration file for a table in your db.
In my rails App I have three models/tables in the database (users, registrants, events). I was setting up some Capybara/RSpec tests when I ran into an issue saying it could not find the events table.
Now the events model has been working fine, I've been able to create events, go into the rails console and query things such as Events.all or Events.find(1). What is confusing me is my schema. My schema has
create_table "registrations", force: true do |t|
t.string "first_name"
...
end
create_table "users", force: true do |t|
t.string "email", default: "", null: false
...
end
But there is no reference to the events table. It's been some time since I generated the model for Events but here is the migration:
class CreateEvents < ActiveRecord::Migration
def change
create_table(:events) do |t|
t.string :name
t.string :location
t.timestamps
end
end
end
I have ran commands such as rake db:reset and rake db:migrate to make sure all my migrations are current. Any ideas why the events table is not in the schema?
UPDATE:
So I've deleted the DB and Schema and began migrating each migration one at a time. The events table is there when I run the migration to create it, but after I run the following command the table disappears from the schema:
class AddingAssociationsToEventsUserModels < ActiveRecord::Migration
def change
add_column :events, :belongs_to, :user, index: true
end
end
Here is the migration being run:
rake db:migrate:redo VERSION=20150518132834
== 20150518132834 AddingAssociationsToEventsUserModels: migrating =============
-- add_column(:events, :belongs_to, :user, {:index=>true})
-> 0.0006s
== 20150518132834 AddingAssociationsToEventsUserModels: migrated (0.0006s) ====
That's because test database and development database are not matched.
Run:
RAILS_ENV=test rake db:drop && rake db:create && rake db:migrate
or
RAILS_ENV=test rake db:test:prepare
or
RAILS_ENV=test rake db:reset
Any of the above should work.
Ok so the issue was a mistake in my migration file. Here is what I changed my migration to:
class AddingAssociationsToEventsUserModels < ActiveRecord::Migration
def change
add_reference :events, :user, index: true
end
end
Now the events table is in my Schema and the test can find the table and is passing!
I created a column in a table as normal and did rake db:migrate. I then realised that I needed to set a default value for the column. After looking on stackoverflow I found several people that said all I had to do was edit the migration file so that this
def change
add_column :accounts, :equipment_visible, :boolean
end
turns into this
def change
add_column :accounts, :equipment_visible, :boolean, default: true
end
I did this then ran rake db:migrate again but nothing happened.
I kept looking on for answers as I assume it didn't work because I had already run rake db:migrate.
I then ran another migration and put this into the file;
def change
def up
change_column :accounts, :equipment_visible, :boolean, default: true
end
def down
change_column :accounts, :equipment_visible, :boolean, default: nil
end
end
but still nothing has happened....does anyone know how I can go about this now?
Many thanks
*EDIT
The schema for the table is like this:
create_table "accounts", force: true do |t|
t.string "name"
t.datetime "created_at"
t.datetime "updated_at"
t.boolean "crafts_visible", default: true
t.boolean "equipment_visible"
end
I am trying to get the "equipment_visible" to have default: true after it like the "crafts_visible"
You have to rollback your migration and migrate db again:
bundle exec rake db:rollback
bundle exec rake db:migrate
or just run redo task:
bundle exec rake db:migrate:redo
I think you want:
change_column_default :accounts, :equipment_visible, true
My current migrate file is
class CreateMovies < ActiveRecord::Migration
def up
create_table :movies, :force => true do |t|
t.string :title
t.string :rating
t.text :description
t.datetime :release_date
# Add fields that let Rails automatically keep track
# of when movies are added or modified:
t.timestamps
end
end
def down
drop_table :movies
end
end
I try to change release_date type to integer. So I directly change the file to
class CreateMovies < ActiveRecord::Migration
def up
create_table :movies, :force => true do |t|
t.string :title
t.string :rating
t.text :description
t.integer :release_date
# Add fields that let Rails automatically keep track
# of when movies are added or modified:
t.timestamps
end
end
def down
drop_table :movies
end
end
Please pay attention, the release_date type has been changed. But after I run
bundle exec rake db:migrate
It still produce the same schema file as before. I am so confused.
It's probably because you've already run your migration. So before you want to change it, you should rollback it first:
bundle exec rake db:rollback
then you should modify it and run again:
bundle exec rake db:migrate
As an alternative to dropping and upping the migration, you could make a new migration to change the column type.
class ChangeMoviesReleaseTypeToInteger < ActiveRecord::Migration
def up
change_column :movies, :release_date, :integer
end
def down
change_column :movies, :release_date, :datetime
end
end
Just as a side note, release_date is a confusing name for an integer field - most people would expect it to be a datetime as you had originally.
down will remove the table
rake db:migrate:down VERSION=file_name(exclude extension)
up will create with new changes
rake db:migrate:up VERSION=file_name(exclude extension)