On my ruby on rails app i added following code in schema.rb file to create a new table in database
create_table "label_info", :force => true do |t|
t.text "body"
t.string "title"
t.integer "label_id"
end
and then run rake db:migrate command but nothing is happening. I thought it would create a new table in database .
If you read the first line of your schema.rb file you will see:
# This file is auto-generated from the current state of the database. Instead
# of editing this file, please use the migrations feature of Active Record to
# incrementally modify your database, and then regenerate this schema definition.
I would recommand to do rails g model label_info
May be delete :force => true, because since you haven't created the table it keeps to create first.
:force Set to true to drop the table before creating it. Defaults to false.
Either you have to destroy the model and recreate it or you have to change the migration number and rename the file, for the older schema version. You can use current time stamp. like 20150808114518_abc_xyz.rb
Thanks!
Related
How do I add data to a table in Rails?
So far I have created a Rails app that pulls in data from an API. Next, I have ran the command
rails generate model order
and I have /db/migrate/timestamp_create_orders.rb
class CreateOrders < ActiveRecord::Migration
def change
create_table :orders do |t|
t.string :email, null: false
t.string :order_date, null: false
t.string :total_price, null: false
t.string :order_number, null: false
t.string :cust_name, null: false
t.string :zip_code, null: false
t.timestamps null: false
end
end
end
Next, I believe I need to run db:migrate and that will create the table.
My question is, how do I add data to this table? I want the user to visit the app, it pulls in the data, and stores it in this table.
I have found conflicting advice..
Should I just use the advice from here
Order.create(:email=>'fake#fake.com',:order_data=>"...
But other advise seems to say not to do this here and here. Though they are all pretty old
You do not create database entries in migrations, you usually create schema or specify changes in the schema in migration files. You use seeds for creating seed data in the database.
To create new data in database through rails you can use either create or new method but you need to save the data as mentioned in other posts in your links when you are using new method.
While creating or migrating a new database table, table row is not automatically added. You need to add them manually. One way to populate the newly created database table is using seeds.rb file which is located in your application db folder. You can add Faker gem to your application for creating fake table attribute elements. An example using faker:
(1..3).each do # it'll create 3 new order
Order.create(email: Faker::Internet.email, order_date: Faker::Date.between(2.days.ago, Date.today))
end
Then run rake db:seed in your project folder console.
If you have some validation in your order.rb file, then you can create new instance of that order and then save it like:
order = Order.new(....)
order.save(validate: false)
Ok so you've built your model 'rails generate model test (inputs)' you've rake db:migrate checked your schema file all looks good and working and writing to sqlite. But then you realise you need another attribute in the DB. One way is to rake db:rollback, make change in the migrate file, rake db:migrate again and hey presto all looking good. However doing rake db:rollback has lost all my data already stored in the sqlite. So I'm guessing this is not the correct way to do this? What is the best way?
class CreatePosts < ActiveRecord::Migration
def change
create_table :posts do |t|
t.text :title
t.text :requester
t.text :requester_email
t.text :customer
t.text :contact
t.text :customer_email
t.text :customer_phone
t.string :type_of_change
You can generate a new migration with rails g migration <migration_name> (eg. rails g migration add_foo_to_blah) and then inside that new migration, make the changes you need.
eg. you can add new columns, rename columns, etc.
For more information: http://guides.rubyonrails.org/migrations.html#creating-a-standalone-migration
In fact db:rollback is best way. Of course when you do db:rollback it will wipe away your existing data,but you need to do db:migrate to get the data appear again in the tables.
If you don't want to do rake db:rollback,then create another migration file which will do the job for you.
Edit
You need to perform the below command to get that column added in your posts table.
rails g migration AddImplementerToPosts implementer:text
and do rake db:migrate to make sure that column added in your table.
Yes, db:rollback takes back the last migration, so if in last migration you added some columns, db:rollback will remove them (and if you change the migration and run it again, these fields will be added, but data is already lost).
The proper way to add more fields is to generate new migration and add these fields there.
hy
A lot of time when i run rake db:migrate i get an error because the table user or foor or bar exist.
I try to check the existence of table, but that didn't work and i dont know why .
I use rails 3.2.2
class AddDeviseToUsers < ActiveRecord::Migration
#def self.table_exists?(users)
# ActiveRecord::Base.connection.tables.include?(users)
#end
if !table_exists?("users")
def change
create_table(:users) do |t|
## Database authenticatable
t.string :email, :null => false, :default => ""
t.string :encrypted_password, :null => false, :default => ""
end
end
end
You can check the existence of a table with the following command. This question has already been posted and answered here.
ActiveRecord::Base.connection.table_exists? 'users'
However, your code contains errors. You cannot define a method inside an if block with the syntax you're using. Put the block inside your method, instead.
def change
if !table_exists?("users")
# ...
end
end
Also, you should not be getting this kind of errors often, as you state. Migrations are applied sequentially. Creating your users table in a separate migration before adding Devise to it would take care of that problem. If you run into this problem while migrating an existing project from scratch, consider using rake db:schema:load instead.
In your command terminal type in
sqlite3 db/development.sqlite3
then you can search through your database by SQL command. Use .tables to list all tables in the database and you can see if yours is missing or not.
You can also just look at your schema file to see if the migration worked. The table along with all of it's attributes will be listed there.
You should never have multiple migrations that both try to create the same table. You also should not experience errors like this if you're working with rails migrations correctly.
The way rails migrations work is that every time you run rake db:migrate, for every migration file that runs successfully, it stores the number part of the migration file 123456789_create_users_table.rb (123456789 in this case) in a table in your db called schema_migrations. This way if a migration has already been run, it will never get run again.
It doesn't sound like you're working with rails migrations correctly. I suggest reading this thoroughly: http://guides.rubyonrails.org/migrations.html
If you look in db/schema.rb you will see something like:
create_table "users", :force => true do |t|
What does the :force => true mean?
From the Rails docs:
:force
Set to true to drop the table before creating it. Defaults to false.
Basically, this helps ensure database integrity. If you're manually tooling around with your migrations, it's helpful to ensure that you're creating new tables from a clean slate, rather than risking naming conflicts that stem from tables that have been created on a one-off basis.
This simply drops the table before creation. Check the docs for more info here: ActiveRecord::ConnectionAdapters::SchemaStatements
I'm getting an error:
SQLite3::SQLException: no such column: ideas.list_id:
SELECT "ideas".* FROM "ideas"
WHERE "ideas"."list_id" = 2
But I added
t.integer :list_id
to my db migration file:
class CreateIdeas < ActiveRecord::Migration
def change
create_table :ideas do |t|
t.string :name
t.text :description
t.string :picture
t.timestamps
end
add_foreign_key :ideas, :lists
end
end
which gave me this:
class CreateIdeas < ActiveRecord::Migration
def change
create_table :ideas do |t|
t.string :name
t.text :description
t.string :picture
t.integer :list_id
t.timestamps
end
add_foreign_key :ideas, :lists
end
end
and then I typed
rake db:migrate
Any idea why I would be getting an error saying there's no column? I'm still new to RoRs. Do I have to add a column some other way?
Thanks
As Speransky suggested, you should never modify old migration files. Rather you should create a new migration that adds the desired column. For instance, in this case you would run the following command in your app to create the new migration:
rails generate migration AddListIdColumnToIdeas list_id:integer
And Rails would generate the migration file automatically and the only thing left to do is run rake db:migrate.
If you insist on modifying the old migration file, you can add the column as you did and run the following:
rake db:drop
rake db:create
rake db:migrate
Which will destroy your current database, create a new one and run all the migrations (which will include your new column).
If you want to add a new column to an exist database, you should use rails generate migration. So you can try rails generate migration add_list_id_to_ideas list_id:integer and then use rake db:migrate to commit this change.
You should not add new rows to old migrations. Migration is a step of building database. And number of last executed migration is stored in schema, and it will not be run or redone if you use will use rake db:migrate. If you run the migration with creating the table before, then you should create new migration where you may use add_column method.
migration file name has the datetime encoded in its name so rails run this migration one and do not run it again unless you do a rollback
and here come the magic of migration to build you db with small steps so no need to update a migration after run rake db:migrate , you should make a new migration to do the change you want to your db schema
and remember to
remove the added line form the old migration file as it might raise errors if you decided to rollback this migration
Rails 4.0 easy way to add single or multiple column
https://gist.github.com/pyk/8569812
You can also do this ..
rails g migration add_column_to_users list_id:string
then rake db:migrate
also add :list_id attribute in your user controller ;
for more detail check out http://guides.rubyonrails.org/active_record_migrations.html
If you already have files in your migrate folder, you could just add column you want there(just type the code), delete development.sqlite or whatever represents your db file, and run rake db:migrate.
It will then create a new sqlite file with new column in table, and you can check it in schema.rb
So, basically, everything you did seems good, except you didn't delete your database file.
Doing this seems the easiest for me, all though you will lose all the files in your database. If you're just testing and developing Rails app, this works.
Can anyone comment if there is something wrong with this approach, besides what i wrote?
Edit: I actually found an answer about that here
Editing Existing Rails Migrations is a good idea?