Using rails 3.2.8 ruby 1.9.3 p362.
There is something seriously amiss with my rails app. After so many db issues with an app, I STARTED FROM SCRATCH - read: rails new < new app name>
And started adding scaffolds and models. All in the past hour or so.
Then I tried to migrate a model called Product and I got the "Mysql2::Error: Table 'products' already exists" message when I ran rake db:migrate
Lo-and-behold my schema.rb file transformed itself into the mess of a file I had on my old app (on a different folder).
How can this happen? And how can I fix it?
Also, how often should I be pushing to git? I pushed once before building 2 new models and I already have a mess in my hands.
Help, please!
Did you clean up the old database for migrations from your older app / create a new database for the new app? Looks like it is the older database which is causing the issues.
You can go to your mysql prompt, and do a drop database database_name; and recreate an empty database using create database database_name.
Related
Been able to make migrations (add columns etc) on my local machine with mysql.
But when trying to push these migrations to Heroku, they continue to fail.
The first table in my migration file gets tagged with:
Mysql2::Error: Table 'xxxxx' already exists
locally all my migrations showing as:
up 20171127214206 Add tags to business
but when running heroku run rake db:migrate:status
down 20171127214206 Add tags to business
i don't mind losing all the data at this point as i'm working in a development version on Heroku and will merge later with production
been working on this issue for over a day, so any and all advice appreciated.
according to this and many other sources, it appears you're better to use postgresql adapter with heroku. If you want to do that, you need to edit your database.yml similar to this
I am still new to rails and I have some questions regarding rails migration.
I am using rails 5, windows 8. I generated a model and wrote some code which creates a table with columns. Then I deleted that table from my development db (MySQL) and tried to execute db:migrate again to see if it would create the table and columns written in the migration file. After executing db:migrate, it didn't show any messages in the terminal and it did not create the table and the columns.
Based from my observation, deleting the version of my migration file from schema_migrations and running db:migrate once again, it worked and created the table and columns.
I would like to ask the pros of rails development on why is this happening and what should I do when I start to develop a large database model.
I would also like some suggestions about great resource materials for learning ruby on rails.
Thanks!
Its because rake db:migrate is running only migrations for the current env that have not run yet. So if you run db:migrate and then manually delete table form DB, your app does not know that.
MIgration Guides
I know this one sounds kind of backwards! I've been working on a cloud-based case-management application, and was working on a support-ticketing feature. We have our development database (MySQL) that has all the same data as our production database (It's a very large app). Development is basically a "sandbox" environment, hence why the development db has all the same as the production db. This morning, I ran into a problem in my local development server for:
Migrations are pending; run 'bin/rake db:migrate RAILS_ENV=development' to resolve this issue.
Alright, did that, even though it didn't make any sense. It err'd out, because it was trying to create tables that already existed (I had already ran my migrations, the features were completed a day ago! And everything worked great).
The only thing that I did the moment before I got this message in my development server was uncomment an entirely-commented-out file to try and fix problems with TinyMCE (/config/tinymce.yml, text editor), followed by restarting my rails dev server. All this file was, was a bunch of defaults and plugins. When I saw the problem, I first commented them all back out. Still the same error. Proceeded with rake db: tasks.
Started looking for answers.. kept getting errors. Made a noob mistake, and ultimately did a
rake db:migrate:reset
which I knew would rebuild the schema at the cost of hosing the db. This failed.. But we do have the db in more than one place (since it's the same as production.) Also, just to try and bring all the tables back:
rake db:schema:load
....failed on one of the tables anyway with
ActiveRecord::StatementInvalid: Mysql2::Error: Specified key was too long; max key length is 767 bytes: CREATE UNIQUE INDEX `login` USING btree ON `users` (`login`, `intranet_id`)
..and all the tables are empty (as expected) that were successfully created. I'm by no means a database pro (I haven't dev'd very long). Am wondering, is there a way to copy the entire production database into the devel database? Tables, data, and all. Or any other suggestions? Really lost on this one.
You can use mysql_dump.
If you connect to the database everything is there - you just have to do a dump of the full database and then do the dump again into the production tables.
As you clearly see you can output from the database with ">" and you can import with the "<".
I am using mysql database with following tables and columns:
table masterProduct: (id,name,description, image).
everything is already set&ready in database.yml(connected with database) file, and in Gemfile (gem 'mysql').
When i do :rails new Product , i would like to load all the info i have in database but as scaffold, so i can edit/delete items which are already there or add new ones.
I've been looking on some tutorial like, http://www.tutorialspoint.com/ruby-on-rails/rails-scaffolding.htm but it didnt help me a lot, since he created a database manually, and i used PHPMADMIN.
Any sugestions?
Thanks,
Michael.
Manage your database manually is very bad idea. Rails has awesome features to do this like migrations, seed, etc. When you need update your db schema, you create a new migration to do that. This is the best and easy way. But...
Dynamic scaffold was removed in Rails 2. However you have some options:
1) You can try the gem activescaffold. Other gems like rails_admin or activeadmin are awesome to generate admin views.
2) When you execute
rails generate scaffold Product id:integer name:string description:text image:string
the generator will generate the scaffold files with a migration to create your table. So you can execute rake db:migrate to update your database schema. You can try execute this generate without execute the rake command once your table already exists. This will not create the file db/schema.rb and you will need to manager database manually (bad idea).
So my Mac went down and now trying to build my project on my new Mac. I need to know when running rake db:migrate does it look at the schema.rb file?
As I am getting
Mysql::Error: Table 'myproject_development.users' doesn't exist: SHOW FIELDS FROM `users`
Even when I run rake db:migrate:up VERSION=001 which has no reference to users I get the same error?
If it matters my migrations start like
001_...
002_...
003_...
20100222171241_...
The migration code generally doesn't look at the schema file. It looks at the names of all the migration files and the database table called schema_migrations, and determines which migrations haven't been run yet. (I believe it does dump the schema at the end of running migrations.) Either your missing a migration, or your schema_migrations table is out of sync with your database.
After making a backup, you can start to troubleshoot. Do you have a migration that creates the users table? If not, where did it go? If you have it, why isn't it running?
FYI The migrations that start with numbers (eg. 001) are older versions of migrations. Sometime around 2.2 or 2.3 the names of the migrations were changed to dates, which is what you are seeing in the later migrations.
There may be a problem with the way those first few migrations are named, and they are not being found (I can't remember the migration story when this naming scheme switched). And maybe it tracked the migrations differently back then so there may be some futzing to make it work with the more modern scheme. You can fairly safely rename them following the new scheme, using the datestamp of the file.
Hope this helps.