After upgrading from rails 5.1 to rails 6.1 the entries are getting deleted from the schema_migrations table except for the last entry.
I am facing this issue in all the environments. For the test environment, I fixed the test environment by commenting on this line ActiveRecord::Migration.maintain_test_schema! but in the development and non-production environment, I am still facing the issue.
I try to google it but I don't see any article related to it. Could anyone give some insight on it?
Rails 6.1.0
ruby 3.0.0
activerecord-oracle_enhanced-adapter 6.1.4
Database Oracle
Just delete the migrations if you have no pending changes.
https://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you
Migrations, mighty as they may be, are not the authoritative source
for your database schema. Your database remains the authoritative
source. By default, Rails generates db/schema.rb which attempts to
capture the current state of your database schema.
It tends to be faster and less error prone to create a new instance of
your application's database by loading the schema file via bin/rails
db:schema:load than it is to replay the entire migration history. Old
migrations may fail to apply correctly if those migrations use
changing external dependencies or rely on application code which
evolves separately from your migrations.
Related
I recently deployed a website to heroku and I am having problems with the database. I am using ruby on rails and when I first created my local databases I used SQLite. When deploying to heroku I had to change my databases to Postgres and in the process several migration files got removed and changed into a single migration. Now, when I run the postgres database on my localhost, I am still seeing all of the columns in my database, but when I visit the page on heroku one of the columns is missing.
I have checked both my local console and the heroku console and the databases are now different. The local console includes all of the columns in the database and the heroku console is missing one of the columns in the database, but is generating all of the other columns correctly. I have tried running a rake task on heroku and have pushed the most recent changes to heroku.
I tried to to add an additional migration to add the missing column to the database, but whenever I try to rake the migration it tells me that attribute already exists. Any help I can get is appreciated!
The best way to set up your database on heroku is with
rake db:schema:load
From the guides on migrations
Migrations, mighty as they may be, are not the authoritative source
for your database schema. That role falls to either db/schema.rb or an
SQL file which Active Record generates by examining the database. They
are not designed to be edited, they just represent the current state
of the database.
There is no need (and it is error prone) to deploy a new instance of
an app by replaying the entire migration history. It is much simpler
and faster to just load into the database a description of the current
schema.
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.
Since doing migrations with rails + git is type of a pain, a new thorn has sprung..
Before I am doing any harm to my prod DB, would the following situation cause havoc? If so, how would I handle it?
I am working a long-term feature in a separate branch (feature/long-term). This feature is an overhaul of a lot of components and it will take awhile to complete. This feature has new migrations, which were migrated to the localhost DB.
meanwhile, I need to fix/add a migration to the prod system via another branch (feature/quick-fix). This has a migration file with date later than the feature/long-term migration.
The migrations of the quick-fix and the long-term have nothing to do with each other, they do not collide and work on separate tables. It doesn't matter what order they are run.
If I merge feature/quick-fix to master and db:migrate and in a few days/weeks merge feature/long-term the migration files order would be the long-term first.
Would this affect the DB in some way? (the prod DB is important, so I don't want to reset)
What you described is a very common development workflow (especially so in teams with more members) and it's perfectly safe for your production DB.
Rails, as of version 2.1, is smart enough to keep a list of all migrations ever run, instead of just the latest migration version run. This information is stored on a separate table aptly named schema_migrations.
So, if you push a new migration today, say 20140527_quick_fix.rb, and a month after that you push a new (but with an older timestamp) one 20140101_long_term_feature.rb, Rails will still know that the latter was never run in your production environment so during rake db:migrate it will process it, as you would expect. The newest won't be run again of course as the Rails would know that it has already been processed.
From the official documentation:
Rails versions 2.0 and prior used to create a table called schema_info when using migrations. This table contained the version of the schema as of the last applied migration.
Starting with Rails 2.1, the schema_info table is (automatically) replaced by the schema_migrations table, which contains the version numbers of all the migrations applied.
As a result, it is now possible to add migration files that are numbered lower than the current schema version: when migrating up, those never-applied “interleaved” migrations will be automatically applied, and when migrating down, never-applied “interleaved” migrations will be skipped.
In section Rails Database Migrations of Ruby on Rails Guides, there is one line saying that
The db:reset task will drop the database, recreate it and load the current
schema into it. This is not the same as running all the migrations.
Can anyone tell me where exactly they are different and why it is more error prone to replay the migration history?
I'm fairly new to Ruby on Rails. Thanks in advance.
The schema file contains the current structure of your database. When you load it, you are guaranteed to have the exact schema in your db that is in the file. Migrations were designed to make incremental changes in the database. You may add a table, then some columns, and then remove the table in three separate migrations. There's no need to go through all this when the schema already knows that the table no longer exists.
On why they are error prone, I'm not totally sure. The one thing I can think of is that migrations can be used to make changes to data and not just the structure.
Running rake db:reset will rebuild the structure of your database from schema.db, which essentially works as a cached version of your migrated database structure. Running all your migrations, on the other hand, applies the migrations one by one, which may include arbitrary code to accomodate for changes to the database (e.g. prepopulate an added counter cache column).
It can be more error prone to replay the migration history, since it is the product of changes to both the structure and data of the database. If the developers haven't been careful, it might not apply cleanly to a fresh environment (e.g. the migration assumes an old version of a model). On the other hand, schema.db can get out of sync if you edit a migration once you've migrated (a useful trick to avoid migration explosion during development). In that case, you need to run rake db:migrate:reset.
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.