I've removed my migration files thinking that it shouldn't matter since I could load from the schema. However, I'm getting warnings in heroku that it could be destructive.
Is there a safer way to update your db from the schema when your migration files are deleted?
Related
Is advisable to do a rake db:rollback when I am wrong in a field of the database; then a rake db:migrate to create the correct structure of the database?
In development environment that might be an option.
But as soon as you pushed the migration to a remote repository and another developer ran that migration against his database or the migration ran on staging or production, you should not change the migration anymore.
Instead, add just new migration in such cases.
I have a ruby on rails application already running in production. The database has records which I do not want to loose. I had to add and run new migrations to add some new columns to existing tables. The migrations run successfully and the schema.rb file reflects the changes but the changes do not appear in the database or existing table structure.
Based on research online, rake db:schema:load updates the db based on the schema.rb file. But this resets the database.
It is crucial that I do not loose the data in the tables.Is there any way to solve this? I am fairly new to ruby on rails.
I was able to fix it. I checked the status of migrations in the production environment rake db:migrate:status RAILS_ENV=production and realised they were down. I then run rake db:migrate RAILS_ENV=production and that did it. Changes now reflect in the db. Thanks #muistooshort for the nudge in the right direction
If I understand correctly, if I run:
rm deveopment.sqlite3 schema.rb
It will delete the database file and the schema files and then I re-create the rake db migrate file but would I have to delete the whole blog and start from scratch or will these commands let me keep the blog structure files loaded and just recreate the database? Not sure which option is the best.
The .sqlite3 file is the actual DataBase in a SQLite installation.
The schema.rb file is a point-in-time representation of the database structure. This means that every time you alter the structure of a database (add a table, remove a table, add a field to a table, add or remove an index etc.) this file will be changed by rake to reflect the current structure of the database. Note that no data is in that file.
If you erase the database (and the schema.rb file for that matter) a
rake db:setup
would actually execute the following three rake commands:
rake db:create
rake db:migrate
rake db:seed
So if you have your migrations intact and your seed file intact, erasing the schema.rb and the *.sqlite3 files will erase that database (and all its data) and the reflect of the current database schema, but not the migration files or the seed data. You will be able to regenerate the database (with only the seed data, no other data) with a
rake db:setup
Take note that the development.sqlite3 is one of the 3 different databases that might exist, others being production and test.
But, if you are willing to reset the base, a better approach would be a
rake db:reset
Please read Migrations Guide if you need more information about it.
I started building my app in PHP but was convinced by some developer friends to change to RoR instead. Since I already had my database structure designed and created in mysql, I never used any rails migrations to create tables; I just created the appropriate models to match the existing database schema.
So, now I am at the point where I want to test deployment and, of course, I have no migrations to rake to recreate the db on, for example, Heroku.
I know that I can simply go back and recreate the database by creating migrations but my app has dozens of tables with hundreds of fields in total.
Is there any way to create a set of migrations based on my existing db schema, or will I just have to knuckle under and build the migrations one by one to recreate the structure via rails' migrations.
Actually, there are some rake tasks to do the work:
rake db:schema:dump # Create a db/schema.rb file that can be portably used against any DB supported by AR
rake db:schema:load # Load a schema.rb file into the database
You can run: heroku run rake db:schema:load.
I'm a newbie in Rails and I'm trying to deploy my first project.
I'm using rails 3, ruby 1.8.7, Passanger, Mysql and Git
I followed a lot of tutorials to learn about deploying with capistrano and there is a question that i can't figure out.
In the tutorials they never talk about schema.rb
If this file is the responsible for the migrations that i already done and when we deploy the application, capistrano copy all files to the "current" folder (schema.rb to), how can it do the right migrations on production server. Should i tell capistrano to make a simlink to the right schema.rb file for the "current" folder? if yes how can i do that?
Tnks.
The schema.rb file contains the database definition. It is not responsible for any migration.
The migrations are contained in the db/migrations folder. When you deploy a new release and ask Capistrano to migrate the current database, Capistrano invokes rake db:migrate. The migrate task doesn't rely on the schema.rb. It connects to the database, reads the list of executed migrations from the schema table and execute all the files in the db/migrations for which a record doesn't exist in that table.
The schema.rb file is only used when you invoke rake db:schema:load or when you bootstrap Rails. In the latter case, Rails will use the schema to prevent inspecting the database structure every time you access a Model.
That said, the schema.rb file must be versioned in your SCM and you have to include it during deployment. You don't need to do anything special. Capistrano checkout the file from your SCM like all the other files, unless you ignored it.