I got some problems about my database.
I've generated a model Comment once, but this Comment migration not what I wanted, so I drop it, and succeeded to drop. Now I try to re-generate it, and keep running rails db:migrate, but something went wrong.
It shows :
"PG::DuplicateTable: ERROR: relation "comments" already exists",
I've checked my schema.rb, did not have this comment table.
My database using "psql", and Rails version is "Rails 6.0.2.2". I've been searched related problem, but seems like not what I faced.
according your description, I have also encountered this, this is what I tried and solved:
psql
rails db
\d:
drop table tablename;
hope to solve your problem
If the data is not important you could just start fresh by dropping the current database and create a new one
rake db:drop
rake db:create
rake db:migrate
If you are sure that those migrations already have been run before, then you can go and modify the schema migrations table directly where rails stores all migrations that have been run already.
First log into your postgres and choose the correct database
sudo -u postgres psql
\c db_name
then to view the current migrations in the schema table
select * from schema_migrations;
that will show you the current migrations that rails considers as done.
Then check you migrations folder, get the version of all the migration files you want to skip running, the file name starts with the version
for example
20200401212538_add_country_name.rb
the first numeric 20200401212538 part is the version
then insert them into the migrations table
insert into schema_migrations VALUES ('version_of_migration');
Or you could also delete migrations so you could re-run them if you want to.
After that running rake db:migrate should work just fine without trying to recreate the tables.
Another solutions you might consider is that in your migrations you check first if table exists or not before trying to create it.
I feel like this must be a question that has been answered in the past but I could not find anything with Google.
According to the Rails guides:
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.
However, when you load the database via the schema file there would be no data in the schema_migrations table and therefore any migrations that are added to the project in the future cannot be run without first running the entire migration history.
Am I missing something here? If I create a new instance of the Rails DB from a schema file how can I run any future migrations against it?
It is preferred to set up a new database with a schema load rather than running old migrations, and it should be expected that the schema_migrations table is updated correctly when running a rake db:schema:load. When you run rake db:schema:load the schema_migrations table should be populated based on the value of the version key-pair passed to the ::define method in the db/schema.rb file.
For example:
ActiveRecord::Schema.define(version: 20161208214643) do
end
should update the schema_migrations table up to the migration listed in version. The version value should be populated in the db/schema.rb file automatically after running a rake db:schema:dump or rake db:migrate (which invokes db:schema:dump). This allows for any future migrations to be run normally, as should be expected.
The inserts into the schema_migrations table are handled by the assume_migrated_upto_version method, as seen in the following files:
https://github.com/rails/rails/blob/5-0-stable/activerecord/lib/active_record/schema.rb#L52
https://github.com/rails/rails/blob/5-0-stable/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L1021
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 dropped my table successfully from the database from the console, using
ActiveRecord::Migration.drop_table(:foo),
But for some reason the table data still shows in the schema file.
I would like a method to do this without having to manually remove the data, (Doesn't give a proper rails feeling to it.)
The schema file located in db/schema.rb was most likely generated the very last time you ran rake db:migrate. This is because rake db:migrate migrates your db through all of the migrations in your db/migrate folder, and then it calls the db:schema:dump task, which generates the schema file based on the current state of the database.
For your situation, after you have run ActiveRecord::Migration.drop_table(:foo) in the rails console, the current state of your database (now, no longer having the table foo) is not in sync with the schema.rb file that was generated when you last migrated.
What you want to do at this point is re-dump the schema based on the current state of the database, and you do this by running rake db:schema:dump. This will take the current state of your database (without the table foo) and generate your db/schema.rb file.
For more information on the schema file and its relationship to migrations, I would recommend looking at the Rails Guide on Active Record Migrations: Schema Dumping and You.
While the answers provided here work properly, I wanted something a bit more 'straightforward', I found it here: link
First enter rails console:
$rails console
Then just type:
ActiveRecord::Migration.drop_table(:foo)
Where :foo is the table name. And done, worked for me!
I have two machines... a development machine and a production machine. When I first brought my rails app onto the production server, I had no problem. I simply imported schema.rb by running rake db:schema:load RAILS_ENV=production. All was well.
So, then on my development machine, I made some more changes and another migration, and then copy the new application over to the production machine. I then tried to update the database by running rake db:migrate RAILS_ENV=production. I get the following error:
"There is already an object named 'schema_migrations' in the database."
I'm thinking to myself, ya no kidding Rake... you created it! I ran trace on rake and it seems as if rake thinks it's the first time it's ever ran. However, by analyzing my 'schema_migrations' table on my development machine and my production machine you can see that there is a difference of one migration, namely the one that I want to migrate.
I have also tried to explicitly define the version number, but that doesn't work either.
Any ideas on how I can bring my production server up to date?
Update:
Let me start off by saying that I can't just 'drop' the database. It's a production server with a little over 100k records already in it. What happens if a similar problem occurs in the future? Am, I to just drop the table every time a database problem occurs? It might work this time, but it doesn't seem like a practical long term solution to every database problem. I doubt the problem I'm having now is unique to me.
It sounds like the 'schema_info' table and the 'schema_migrations' table are the same. In my setup, I only have 'schema_migrations'. As stated previously, the difference between the 'schema_migrations' table on the production server and the development machine is just one record. That is, the record containing the version number of the change I want to migrate.
From the book I read, 'Simply Rails 2', it states that when first moving to a production server, instead of running rake db:migrate, one should just run rake:db:schema:load.
If it matters, I'm using Rails version 2.1.
This is a guess, I admit: I think that because you first ran db:schema:load instead of db:migrate in your production environment, you got the structure of your db, but not the data that migrate populates into your schema_info table. So now, when you run migrate in the production environment, there is no data in schema_info which is why migrate believes that it hasn't run yet (because it hasn't).
That said... you say that you have looked in the "schema_migrations" table, and that there is a difference of one version from dev to production... I haven't heard of that table, although I'm a few months behind on my rails version. Maybe you could try creating a "schema_info" table in the production environment, with a single "version" column, and add a row with the version that you believe your production environment to be on.
If you get "There is already an object named 'schema_migrations' in the database." error message then I suspect that you are using MS SQLServer as your database? (As this seems like MS SQL Server error message)
If yes then which ActiveRecord database adapter you are using? (What is your database.yml file, what gems have you installed to access MS SQL Server database?)
Currently it seems that Rails does not find schema_migrations table in production schema and therefore tries to create it and this creation fails with database error message. Probably the reason is upper/lower case characters in schema_migrations table name - as far as I understand MS SQL Server identifiers are case sensitive.
Depending on the system used in production, I have seen instances where the below does not work:
rake db:migrate RAILS_ENV=production
But where this one does work:
RAILS_ENV=production rake db:migrate
Quirky, I know, but it's worth trying it to see if it makes a difference.
Regarding your update:
I don't understand what the difference is between your production schema_migrations and the dev version. Is there a record in both tables (there should be just 1 column, "version", right) or is there a single record in the dev DB and zero records in production? If there are zero records in the production table, then do this:
ActiveRecord::Base.connection.execute("INSERT schema_migrations (version) VALUES(#{my version number that production is supposedly on})")
Alternatively, you could try dropping the schema_migrations table totally on production:
ActiveRecord::Base.connection.execute("DROP TABLE schema_migrations")
Then, re-running rake db:migrate RAILS_ENV=production. That will run migrations from starting from version 1 though, which is probably not what you're after.
Alternatively alternatively, you could start an IRB session in your production environment, do either a "require" or "load" (I can never remember which, or if it matters) of the migration file that you want to load, and then call MyMigrationClass.up. You would need to manually set the version number in the schema_migrations table after that, as you would still have the problem going forward, but as a quick-fix type of hack, that would work.
I would just drop the DB, add it again and run rake rb:migrate. Brad is correct that when you ran the schema load, it didn't put any records in the schema_migrations table.
This is more complicated of course if there is data you can't lose on the production server. You could get the rake backup tasks (not sure if that is part of core or not) and then run rake db:backup:write on your production database, and then after you get the migrations up to date on production, run rake db:backup:read.
schema_info is from an old version of Rails. schema_migrations is the new kid on the block. You should be able to remove the schema_info table as it'll no longer be used. You'll probably want to search for any issues associated with this name change.
rake db:schema:load will load the database structure from schema.rb. This file is the current representation of the database structure. It's used when you have an empty schema (database) that needs all the tables and indexes creating. It saves you having to run all the migrations. If you have an existing production database with data in, you don't want to run it. As others have said that would be bad!
I know this post was some time ago, but I stumbled across it and it hasn't really been answered. As it comes up on google, here goes.
When you did a rake db:schema:dump (or when this was done for you by the build scripts) it will have put the definition of the migrations table into the schema.rb. At the end of the script, the process will try to create the table again, however it obviously exists already. Just remove the migrations table from the schema.rb before running rake:schema:load and there will be no error message.
You will need to set the version number in the migrations table to subsequently run migrations. So it is important to know what version your schema.rb relates too, or delete all the old migrations (they're safely in your SCM right?)
rake db:migrate RAILS_ENV=production
Use the db:schema:load task just for the first creation, incremental changes should be migrated.