I am newbie with Rails and trying to make a very simple Rails program. My problem is, when I made a Rails program, at first, I had a mistake and created a database named image by this command rails g scaffold image video title star:integer description:text then I made this command rails db:migrate, when I realized that problem, I deleted image folder and create another folder named Course by this command rails g scaffold image video title star:integer description:text. Everything seem ok.
But, my problem is, when I tried this command rails db:migrate, I saw that nothing happen.
When I accessed the website http://localhost:3000/courses/new to try to make a new thing, I saw that I can not make anything new.
So, I think that maybe my problem is, I made the image folder before the course folder.
How can I work with this problem ?
Could you please give me some ideas ? Thank you very much.
#Juanse Gimenez here is my schema.rb, sorry for my shortcomings
ActiveRecord::Schema.define(version: 2021_01_08_042733) do
create_table "courses", force: :cascade do |t|
t.string "image"
t.string "video"
t.string "title"
t.integer "star"
t.text "description"
t.datetime "created_at", precision: 6, null: false
t.datetime "updated_at", precision: 6, null: false
end
create_table "images", force: :cascade do |t|
t.string "video"
t.string "title"
t.integer "star"
t.text "description"
t.datetime "created_at", precision: 6, null: false
t.datetime "updated_at", precision: 6, null: false
end
end
#borjagvo thank you for your comment, here is my new.html.erb <h1>New Course</h1> it is very simple, so I do not think that it is the reason ?
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.
We're using activerecord 5.1.4 in our project.
When running migrations the SchemaDumper generates different output on different colleagues machines. Some are using Linux others using Mac.
We're all running the same postgres version 9.6
For example Macs generate:
create_table "appliances", force: cascade do |t|
t.string "brand"
t.integer "property_id"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
Linux creates:
create_table "appliances", id: :serial, force: cascade do |t|
t.string "brand"
t.integer "property_id"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
Linux output seems to have id: :serial and it doesn't pad columns to align.
It means we're constantly bouncing changes to schema.rb in version control
Why would the output be different?
They say that a rails paradigm is to not repeat yourself, or "DRY". So I'm working on this quiz app, and now that I've slowly understood how MVC works somewhat and how it's all coming together, I want to write better code. So let's take this example that I did earlier from my schema:
create_table "posts", force: :cascade do |t|
t.text "title"
t.text "text"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.string "user_id"
t.text "answer_choice"
t.text "answer_choice_2"
t.text "answer_choice_3"
t.text "answer_choice_4"
t.text "answer_choice_5"
t.text "correct_answer_choice"
t.string "slug"
t.index ["slug"], name: "index_posts_on_slug", unique: true
end
As you can see, answer_choice, then adding _2, _3, _4, _5 and correct_answer_choice seem very ugly and inefficient to me. What if I want to add a post that only has two answer choices? Or three? Maybe more?
What would be a better way of going about this so it's more adaptable and flexible?
It would be simpler with just a given_answer, and correct_answer columns in your table per post. For your given_answer column, you can use options_for_select to display the choices in your form:
options_for_select([ "Choice1", "Choice2", etc... ])
After submission, you can then query if correct_answer == given_answer to see if the two values match up.
I've noticed this for months and I just didn't have the time to deal with it until now. Whenever my CI server does an automatic git pull and restarts the rails servers, the schema.rb gets randomly modified. As the example shows below, the api_name column of a certain table got dropped. I dropped this column about 3 months ago. Same with transportation_charges. And very often, the spacing in this file changes: see created_at and updated_at.
It's especially annoying since on the next run, when my CI does an initial git pull, it complains about changes to schema.rb and stops execution until they get pushed or reverted. And it's not just the CI server. I've seen this on other developer machines as well. Did anyone run into this before?
diff --git a/db/schema.rb b/db/schema.rb
index 470d3bf..166e3ee 100644
--- a/db/schema.rb
+++ b/db/schema.rb
## -883,7 +883,6 ## ActiveRecord::Schema.define(version: 20170720211740) do
create_table "ups_package_service_options", force: :cascade do |t|
t.string "name"
- t.string "api_name"
t.string "type"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
## -910,9 +909,8 ## ActiveRecord::Schema.define(version: 20170720211740) do
t.string "code"
t.string "name"
t.string "api_name"
- t.decimal "transportation_charges"
- t.datetime "created_at", null: false
- t.datetime "updated_at", null: false
+ t.datetime "created_at", null: false
+ t.datetime "updated_at", null: false
t.boolean "domestic"
end
When you run a migration, the schema gets updated not just by the migration, but also the current database. I'm guessing some of your developers are using databases inconsistent with the schema. Then you'll get unexpected changes every time they run a migration.
Im getting this error when running heroku run rake db:migrate -> ERROR: column "frequency" cannot be cast automatically to type integer I'm not sure what I'm supposed to do in order to fix this error. Here is my schema local that works fine when I migrated:
schema:
create_table "assignments", force: :cascade do |t|
t.string "name"
t.string "description"
t.integer "account_id"
t.datetime "created_at"
t.datetime "updated_at"
t.string "attachment"
t.integer "finished_count"
t.datetime "start_at"
t.datetime "end_at"
t.integer "frequency"
t.integer "status", default: 0
t.index ["status"], name: "index_assignments_on_status"
end
Cannot I not use integer as a type with PG? if not, what should I do instead?
Without seeing your migration, which you should post. A likely cause is that the frequency column already has data in it. Therefore PG cannot blindly convert that data into a integer if it is not something that is like a number.