I have been working on a rails app for a while now and want to recreate the model without going through all the migration stages (i.e. from scratch) now that I finally have a final design for how I want it to be built.
How do I do this without having to have to recreate my entire project?
If I am understanding correctly about what you want,
rake db:reset
will recreate your database from your db/schema.rb. Make sure that you have run all the migrations before running it.
However, rails manage the database using the migration files in db/migrate. Everytime you make changes to the database you will need to do it through them or you will get into trouble. These files should be retained and whenever you deloy your app to a new machine, running db:migrate should be fine.
I'm not sure if this is what you want, but you could delete all your migration files and copy everything from db/schema.rb to a new migration.
Related
I messed up pretty bad and created a rails application without the test directory on accident. I now need to make a whole new rails application but I have put a substantial amount of work into this first one. Is there a way that I can transfer my schema, migrations and any other database (postgres in this case) related things over to the new application with ease?
You don't really need the migrations if the db is as you want it, you can run rails db:schema:dump if you want to generate schema.rb file. The model files can be safely copied to your new project.
You can also just create a new project and then copy that projects test folder into your old one.
I have created an application with Ruby and Rails. The thing is that when I was develpoing it, I had some problems with the migrations, because I created them but with a wrong syntax. What happened is that I deleted some of the files because sold migrations that didn´t work had the same name than the new ones, but in the middle of that I accidentally deleted some of the migrations (obviously after running rails db:migrate) that the project uses actually. So for instance, i have the Service table, which is related to the Reservation table because Service has reservation_id, but i don´t have the migration file that says AddReservationIdToService.
So now I want to use Heroku for production. the thing is that O have to change to postgresql because Heroku doesn't support sqlite. So i have to run the de:migrate again to create the tables and relationships in the new DB, but I need the files that I explained that I deleted. The question is:
Can I create the migrations manually, so when i run db:migrate for postgres the full structure of the database is created without lacking relations?
You don't really need the migrations to recreate the existing DB -- in fact it's not a good idea to try for a couple of reasons (including the missing migration file problem you encountered). You can simply run:
bin/rails db:schema:load
to populate a new database from the existing schema. If for some reason you haven't got a db/schema.rb checked under version control you can run:
bin/rails db:schema:dump
against the sqlite version to re-create a fresh schema file from the database.
You can also keep your migrations list tidy by occasionally zapping really old migrations, since all the cumulative changes are captured in the schema file.
Yes, you might create another couple of migration files.
Certify you have now the tables you wish locally with your sqlite. Draw these table in a piece of paper (or where it be the best fr you), then check this official API documentation of Rails.
Delete all migrations made before and create another according to the tables you drew.
The workflow is gonna be like:
1) "I need to create a table called Reservation, where is it shown on the documentation?"
2) "I need a table called Service, where is it shown on the documentation?
3) "I need to add a column with a foreign key to service named reservaton_id, how does this documentation says it?
For all this steps above, create the correspondent migration file as you normally have done.
The main difference here is not to run the migration locally. Instead, push your new version app to your heroku remote branch and there you run the migration, like:
heroku run rails db:migrate
Remember to not run this same migration locally because you already have these tables locally.
The last two advise is:
1) If your migration doesn't go as you expect, don't delete the migration file. Instead, run rails db:rollback and try again.
2) Keep tracking your migration files on the same branch of your version control.
I'm trying to launch a Rails project on a new laptop and have some errors in few old migrations (attributes are no longer present for some models etc).
I commented those migrations and rake db:migrate finished successfully. I've got a database dump and everything seems to be working fine.
Is it ok that some migrations were commented? Can it affect something in the future?
You don't need to run all the migrations when preparing a new database instance. In fact for larger projects it may not be possible or too complex.
Instead restore your latest database state from a snapshot if you have one or run rails db:setup to have a database with the latest schema created from your db/schema.rb. Read more in Active Record Migration docs.
Check out your db/schema file which will let you know the state of your database and see if any of your unwanted fields still exist. Commenting is fine, though, it may cause confusion later on.
How to load schema and data for my production rails app into a different machine.
I would like to converge all migrations done so far into a single migration file and point the new instance to a snapshot of the prod db. How to solve
Just copy and paste the schema and do rake db:schema:load. You can also paste the schema.rb contents into a migration, but make sure to delete all other migrations. However keep in mind that there is really no reason to do so, just leave the old migrations as they are.
To import test data use this gem: https://github.com/ludicast/yaml_db .
At some point in my rails development I started making database changes (e.g. dropping or altering columns/tables) without using rails migrations. So now I get errors when I try to deploy my rails app from scratch.
blaine#blaine-laptop ~/tmp/rbjacolyte $ rake db:migrate
(in /home/blaine/tmp/rbjacolyte)
== AddHashToTrack: migrating =================================================
-- add_column(:tracks, :hash, :string)
rake aborted!
An error has occurred, all later migrations canceled:
Mysql::Error: Table 'jacolyte_dev_tmp.tracks' doesn't exist: ALTER TABLE `tracks` ADD `hash` varchar(255)
(See full trace by running task with --trace)
How can I sync my production and development environments with migrations after I've mucked it up by using raw SQL? I want to deploy my rails application without database errors, and I don't want to start from scratch.
The data in the production and development environments match, but the migrations fail. I want a way to 'start from scratch.'
Could I simply delete all of the migrations that I have, and then just start using migrations from now on?
The shortcut way: manually add an entry to schema_migrations for a timestamp that represents a baseline. You can add migrations after that and as long as they don't make any bad assumptions about the db schema they should be able to run just fine. You won't be able to migrate backwards, but that's not a huge problem.
The bigger problem is that you won't be able to make a DB from scratch, which gets to be a pain longer term.
The fix for that is to delete all your existing migrations and create a new one that creates the existing schema. Manually delete everything from the schema_migrations table and put in an entry for this one new migration. After that, you can create new migrations that build on this new baseline and they should apply just fine. You should be able to bootstrap new databases in the normal fashion.
As long as your direct SQL is contained in Rails migrations, there's no problem with using it. Just make sure you implement both the #up and #down methods and you should be good. We've actually taken to using raw SQL as a best practice to avoid problems when models are changed later on. Something like
Foo.create(:name => 'bar')
seems innocuous, until the User model is modified to have
validates_presence_of :baz
At which point the new migration will run against an existing database, but that earlier migration that created the table and added the dummy entry will fail because User fails validation. Just using
execute("insert into foos (name) values ('bar')")
will work fine as long as the later migrations properly populate any new columns they add.
Maybe you could just get rid of all your current migrations, and use rake db:schema:dump to create a new schema.rb file, and manually edit your production database to reflect the changes you've made so far?
I like Veeti's suggestion, with a modification: rake db:schema:dump, then move that file to your development machine. Flatten your Rails migrations so far (see this SO thread on that), get rid of most of your migrations, and re-work your migrations to work, given your new schema.
Get this working on your dev machine, commit and deploy.
If the existing production data is compatible with the development database schema, then I would:
Dump the production data to a file using a program such as mysqldump
Drop the production database
Recreate the production database
Run the migrations against the production database, specifying VERSION=0
Import the production data from the file created at step one
If the schemas aren't compatible then you might be able to follow this process but you'll have to edit the SQL in the file created in the first step to take account of the schema differences.