I transfered a project to a new machine. Everything works. I can run migrations and they update the mysql database. However, the schema.rb file doesn't acknowledge the changes. I checked the read/write permissions for schema.rb are OK. Does anyone have any idea about what could cause this problem. I'm using Rails version 2.3.5. rake:redo rake:rollback don't work because the schema is not aware of the changes in database. running rake db:migrate again does nothing.
The answer was that I had the following line in my development.rb file
config.active_record.schema_format = :sql
After commenting it, everything worked.
I have never encountered this problem but this may solve it:
Take a backup of your current schema.rb cp db/schema.rb db/schema.rb.backup
Delete schema.rb rm db/schema.rb
Run rake db:migrate
This will regenarate your schema.rb file from the current database state.
Related
I'm using a postgres feature that rails schema.rb file doesn't support so I've set config.active_record.schema_format = :sql to ensure that all aspects of my database schema are recorded. However, when I set this option rails seems to stop updating the schema.rb file.
Since schema.rb is far far easier to read and I really only need structure.sql to capture the array_to_string function needed to generate a certain fulltext index I'd like to have migrations automatically update schema.rb as well as structure.sql.
Is there any way to get rails to update both when I run db:migrate without (as I've been doing) changing the config option by hand and then rerunning db:migrate?
Ohh, I'm being an idiot. There are rake tasks db:schema:dump and db:structure:dump. All I have to do is to create a new task that has dependencies on db:migrate and both db:structure:dump db:schema:dump or just run them both on the command line.
I am just testing the production environment in my laptop. I used the command
RAILS_ENV=production rails console
It somehow drops all tables and recreates them and that too picks up some old schema and does that. Now because of that the latest app doesnt run. Same with unicorn
bundle exec unicorn
Any ideas where is it picking up the schema file from. I have deleted the db/schema files as well. I now only have the migrations.
Not because of anything else but schema.rb file. The preload option in unicorn runs the schema.rb file as well and then we loose the data in the database since in the schema.rb file, it is mentioned force=true. Deleted the file and everything worked fine.
Due to some deployment issues I stopped tracking schema.rb in git. Somehow I have stuffed this up and somewhere along the way my schema.rb file has disappeared.
Is there a way of regenerating schema.rb from the database or from the migrations? I would prefer not to lose the existing data.
If you run a rake -T it will list all possible rake tasks for your Rails project. One of them is db:schema:dump which will recreate the schema.rb for the Rails app from the database.
bundle exec rake db:schema:dump
Careful,
rake db:schema:dump
will dump the current DB schema FROM the DB. This means that if you made any changes to your migrations, they will NOT be reflected in schema.rb file which is not what you want IMO.
If you want to re-create the schema from the migrations, do the following:
rake db:drop # ERASES THE DATABASE !!!!
rake db:create
rake db:migrate
RAILS 5 Way:
rails db:schema:dump
or if you Encounter Gem::LoadError then:
bundle exec rails db:schema:dump
Note:
in rails 5 it is recommended that task are generated/executed by using rails instead of rake, this is just to remember, rails generated task are of extension .rake see in lib/tasks/myTask.rake. which means these task can also be executed by prepending rake.
rake db:schema:dump
I think this is still valid in Rails 3 - it regenerates the schema.rb from the database.
Directly from the schema.rb file itself:
If you need to create the application database on another
system, you should be using db:schema:load, not running all the migrations
from scratch. The latter is a flawed and unsustainable approach (the more migrations
you'll amass, the slower it'll run and the greater likelihood for issues).
So do NOT do the suggestion of rake db:migrate, which was suggested in the - at the time of this writing - lowest rated answer.
If you regenerate schema.rb locally, you should be alright. It simply holds a representation of the structure of your database tables. The data itself is not contained in this file.
To regenerate your schema.rb file, run:
bundle exec rake db:schema:dump
Then simply commit the new schema.rb file and you should be in good shape!
I also had a similar problem where my old schema was not refreshing even if I deleted migration.
So, what I did was dropping all existing tables in the database and migrating them again. Then running "db:schema:load" command gave me a fresh schema.rb.
drop table my_table_name // deleted them individually
rake db:migrate
rake db:schema:dump // re-created a new schema
After rake db:migrate:rollback STEP=1, rake db:migrate:reset, rake db:migrate:setup, rake db:migrate:up VERSION=XXXXXXXXX I get the following entry:
Status Migration ID Migration Name
------------------------------------------------------
up 0 *********NO FILE**********
up 20120209023430 Create tasks
How can I get rid of the orphaned entry? I have encountered this problem a few times after raking the db similar to above. Could somebody please explain what exactly causes this.
Thx in advance.
Shahram
You could use rake db:migrate:reset db:seed. It's a little less verbose and will completely wipe your database, re-run all migrations, and then seed your database from the db/seeds.rb file.
I've just released this gem that can solve this issue for good.
The idea of that gem is simple. It keeps all migrated migrations inside tmp folder so that Git ignores them. It's just only your local story. These files are needed to roll back the "unknown" migrations being in another branch. Now, whenever you have an inconsistent DB schema due to running migrations in some other branch just run rails db:migrate inside the current branch and it will fix the issue automatically. The gem does all this magic automatically for you.
Recently, after I deleted some manually created migrations that were named 99999999xxx_createwhatever, each migration I generate now start with 99999999999999xxx_etc
Any idea how to fix this so that they are generated like 2011xxxxxx again?
If you want to keep your data in database, use mysqldump to backup first.
Then reset your migration to version 0 rake db:migrate VERSION=0
Make sure there isn't any 99999999x migration file, then run rake db:migrate
Finally, restore your database.