A company I recently started working for have, at some point in time, managed to delete one of their migration files - or at least that is what I believe. This file created a table of let's say users, but this table has since been removed.
I would normally not mind had it not been for the fact that building the project locally will fail unless I temporarily shoehorn in an early migration that includes this table creation, this is because there are later migrations that both modify columns on this supposed users table and eventually removes the table. What I have done recently is just add it to an existing migration file that was creating some other table, let's say products, which I have been "carrying" around from branch to branch being real careful that I don't commit it.
It looks something like this (examples):
class AddProductsTable < ActiveRecord::Migration
def change
create_table :products do |t|
end
end
end
Which I have changed to:
class AddProductsTable < ActiveRecord::Migration
def change
create_table :products do |t|
end
create_table :users do |t|
end
end
end
I am essentially wondering if committing this would do any harm on production. After all, the migration has already been run so it wouldn't execute it again? I'm very tempted to just do this as it's getting old real fast to always remember to recreate or lug this piece of code around when I need to rebuild, but I don't feel confident enough that something bad won't happen nor have I found much in the way of answers on Google.
PS., I'm the only developer on the project currently and they don't have any other developers who I could ask this question to.
If you haven't already ran the migration, then no problem editing the migration file. Otherwise:
Quoting from rails guides:
In general, editing existing migrations is not a good idea. You will be creating extra work for yourself and your co-workers and cause major headaches if the existing version of the migration has already been run on production machines. Instead, you should write a new migration that performs the changes you require. Editing a freshly generated migration that has not yet been committed to source control (or, more generally, which has not been propagated beyond your development machine) is relatively harmless.
Source: Changing existing migrations
As long as the migration has been ran in production, this should not cause any issues in the production environment. You could even delete it if you must (Note: not recommended if you have other team members as they will face the issue you are facing if they haven't already ran the migration locally).
To check whether a migration has been ran in a given environment you can use the following rake command:
RAILS_ENV=<environment> bundle exec rake db:migrate:status
For example, doing this in development you will get this:
RAILS_ENV=development bundle exec rake db:migrate:status
up 20190201100000 Add soups table
up 20190301100000 ********** NO FILE **********
up 20190601100000 Add supplies table
up 20190501100000 Remove food column from supplies table
up 20190601100000 Add test table
up 20190701100000 Add foo column to test
up 20190801100000 Add products table
down 20191119030000 I havent ran this
The above tells you which migrations have been ran (indicated by up) and which haven't been ran (indicated by down). It also tells you whether there is a file associated with the migration or if the file has been deleted (see the one above with no file). When you deploy your project to production, the down migrations will be ran so modifying the up migrations will not do anything.
I recommend you run the following in production to make sure the migration you are modifying has the down status.
RAILS_ENV=production bundle exec rake db:migrate:status
Related
I added a migration in branch "add_dogs" with migration db/migrate/20221220155010_create_dogs.rb, and ran db:migrate.
Later on, I changed branches (without a merge), and ultimately abandoned the "new_dogs" branch.
Later later on, I checked out "add_cats" branch with db/migrate/20221101010101_create_cats.rb, and ran db:migrate. So far, all is well.
But then I tweak the "add_cats" migration (before committing anything), and ran db:rollback so I can run it again. I get this error:
ActiveRecord::UnknownMigrationVersionError:
No migration with version number 20221220155010.
I can still run db:migrate on new migrations just fine, but not db:rollback or db:migrate:redo.
This makes sense, because the database has a record of applying 20221220155010, but that migration file no longer exists, so there is no way to roll it back.
How can I get past this?
Here are three ways to deal with a missing migration file, depending on your needs and access:
For a quick temporary fix, you can roll back just the migration you're currently editing so you can run it again. This may be useful if the other migration is still in the pipeline on the other branch and both eventually will get merged.
rake db:migrate:down VERSION=20230101010101
// This is the version of the migration you WANT to rollback, not the missing one.
If the missing migration will never come back, you want a permanent fix. The simplest way is to remove that record from the database. You can do this from your favorite SQL client, rails console, etc. (I suppose you could even write a migration to do that, but that seems mighty sketchy.)
DELETE FROM schema_migrations WHERE version = '20221220155010'
-- This is the version of the migration that is MISSING, not the one you are working on.
If you don't have direct access to the database for whatever reason, you can give Rails a placebo to rollback. Ensure the timestamp in the filename matches the missing migration's version number.
Create a file named db/migrations/20221220155010_just_kidding.rb:
class JustKidding < ActiveRecord::Migration
def change
# nothing to see here.
end
end
Then, rails db:rollback will roll back that no-op migration and delete 20221220155010 from the schema_migrations table. You can now delete the placebo migration forever and you'll be in good shape as far as running migrations and rollbacks.
However...don't forget that the effects of the old migration are still in your schema. Maybe you're stuck with a new, unused 'dogs' table or an extra column on a table. Maybe that's benign on your dev box, but you certainly don't want that cruft on a production environment. All the advice in this answer assumes you're on a throw-away environment and that the effects of the old migration aren't a problem. Tearing down your whole database and rebuilding may become a more attractive option in this case.
One of the realy take-aways here is... don't let this happen in the first place! Ideally, you should rollback any new, uncommitted migrations before changing away from a branch. But...things happen...
p.s. If there is a way to do this from the command line, I'd love to learn it. I'm imagining something like rails db:migrate:delete VERSION=20230101010101 might be handy in a hackish kind of way.
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 doing my first project on RoR I decided to use Devise gem for the authentication everything is working fine in Localhost, right now i'm able to sing_up, log_in, reset pass and some other default features that comes with devise.
What I don't understand is how everything gets setup once i push the project into production environment. Let me explain better.
-I see that devise generates db/schema.rb file based on the user.rb model that devise auto generate, these schema i assume needs to be created in the production db.
I have to push the project into git repo but..
1) How the code gets executed once is published
2) How the user table gets created
3) where do I need to specify the db connection (db, user, pass)
In general how is the process to migrate into production env?
I appreciate your help.
In rails db schema is controlled using migrations. Migrations are usually very small files living in db/migrations folder. Each of them defines a single subclass of ActiveRecord::Migration class.
Each migration is supposed to go both-ways, so it has to implement both up and down method (for rollback). In majority of the changes those are obvious (like when up action creates a table, down action should destroy it). For migrations like this you can use change function - rails will create down function automatically (assuming that all actions are reversible - some of the methods even accept extra arguments to make it possible like remove_column :table, :field, :integer. :integer bit might seem redundant here, however the action is irreversible without that information).
You run your migrations using db:migrate rake task. Effectively it will run all the migration which has not been run against current database. When it is done, it will dump your current database into db/schema.rb file. This file is used only as a snapshot of your current database schema, which is of great help if you need to get back to previous version of your application (which is why schema.rb should always be checked into your source control). It is also possible to recreate your database directly from that file rake db:schema:load, however it will cost you all your data.
If you check your database (any environment), you will notice there is one extra table called schema_migrations which does not appear in your schema file. This table contains all the migrations that has been executed against this database. This way rails will not retry migrations that already has been run.
There are many advantages of using migration system:
It is easy for every developer to bring their local database up to the latest schema.
It is easy to rollback your latest changes if deployment failed. (Not always the case)
So how to use it in production? You simply has to point the rake task to the right database:
RAILS_ENV=production rake db:migrate
You can find your database configuration in config/database.yml file. Note that this is the best practice not to store that file in source control and in case of production it is not advisable to store your database password there. Normally you will need to set it through environment variable.
It is important to remember couple of things about migrations:
Never, ever change the existing migration if there is a chance that someone has already run it. Especially, do not modify migrations that has run in production unless you are 100% sure what you are doing (for example fixing rollback). Since database remembers which migrations has run, it might lead to getting your local db out of sync with production db and hence lead to bugs.
Never ever change database schema manually - every change has to be made through migrations.
Well depending on where you're hosting your code you should still do a rake db:migrate to make the changes to the production DB.
If deployed on Heroku, run the following in the console:
heroku run rake db:migrate
Hope that answers your question?
I've run all of my migrations and my schema.rb does not include a "create table" line for table that clearly should exist. The table actually shows up in the rails console too, when I access it via its corresponding ActiveRecord class.
Any ideas why this might be happening? And what the consequences of this discrepancy in the schema could have moving forward? The project appears to be working fine.
You can update your schema.rb to mirror the database with this command.
bundle exec rake db:schema:dump
Schema.rb is not used in development or production so it has no effect on a running application. However it is used when setting up the test database. Can read about it more http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you
I made a new Rails 3 app today, added a simple migration, and for some reason, nothing happens when I do rake db:migrate. It simply pauses a few seconds, then returns to the command prompt, with no errors or anything. Schema.rb and the database stay empty.
Any ideas what could be going on? I've made many apps and never had this problem. Everything is a totally standard setup too.
There's a few reasons why your migrations won't run, but the most common is that the system is already under the impression that all the migrations you've defined have already run.
Each migration creates an entry in the schema_migrations table with the version column corresponding to the identifier number. If you want to force a migration to re-run you can usually back it out and retry it. For example, if you had 20100421175455_create_things.rb then you would re-run it using:
rake db:migrate:redo VERSION=20100421175455
A common situation is that your migration has failed to run in the first place, that it generated an exception for instance, and yet Rails still considers it complete. To forcibly re-run a migration, delete the corresponding record from the schema_migrations table and run rake db:migrate again.
One way to avoid this kind of problem in the future is to define your migrations with an automatic back-out procedure:
class CreateThings < ActiveRecord::Migration
def self.up
# ... (migration) ...
rescue
# If an exception occurs, back out of this migration, but ignore any
# exceptions generated there. Do the best you can.
self.down rescue nil
# Re-raise this exception for diagnostic purposes.
raise
end
end
If you have a mistake in your migration you will see the exception listed on the console. Since the migration has automatically been rolled back you should be able to run it again and again until you get it right.
I faced the same problem. I did a kind of a short hack that helped me. I am posting it just in case anyone wants a short and sweet solution. I agree with what Tadman is saying
"the system is already under the impression that all the migrations
you've defined have already run"
What I did was to change the name of the migrate file in the /app_folder/db/migrate folder. I think the numeric part in the name of the ruby migrate file is the time at which the file was created.
You can add say 1 , to the filename, every time you want to re-run the migrate. After changing the name drop/delete the table (I used mysql command line tool for deleting) and then run rake db:migrate and the migrations should be done.
Calling spring stop might solve your problems.
Well, I found out what was causing my problem. I'm using the slim_scrooge gem and commenting it out makes everything proceed normally. Don't know why though...
I faced similar problem today while migrating plugin for Redmine using
rake redmine:plugins:migrate RAILS_ENV=production NAME=plugin_name
where plugin_name is actually plugin name defined in init.rb of the plugin.
I struggled for 4 hours and finally figured out that my plugin directory name was not the same as the plugin name (note redmine_ prefix):
~/redmine/plugins/redmine_plugin_name
So, make sure your plugin is placed in folder named after plugin name. I believe it applies to other rails apps as well.