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
Related
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've been working on making an auto-deployment system to make updating my django site easier, and it mostly works, but right now my database changes are screwy. I have the auto deployment run "makemigrations" "migrate" then "syncdb"
The trouble I have is when I run migrate, it tells me that my table already exists and can't be created. Previous answers have said to run "migrate --fake", but if I do this, it appears to think everything is up to date. The issue then is that I run "makemigrations" or "migrate" and it says no changes detected (even though there is a missing column from my database). I tried to run "sqlall" to figure out what it thinks the database should be, and it tells me that I have pending migrations. So I tried running "migrate" and it said no migrations exist.
How do I manage this? And in the future, what should I do for database migrations to troubleshoot/fix these problems?
Thanks
I fixed the problem. The issue stemmed from a misunderstanding of how Django migrations worked. Also, as per the comments, syncdb is no longer a command in manage.py.
The original issue was that I had been using a different database for deployment and then I switched and my migrations were out of sync from my development database, so I had to clear out both databases and migrations and start over with my data. Then I run makemigrations on my local machine and migrate there (for my dev DB). Then I upload to the server and have the fab script run migrate on the server production DB without calling makemigrations. This seems to have fixed the issue.
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 "<".
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.
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.