Menu
Does anybody know why whenever I run rake db:migrate in my production environment, the schema.rb file is changed?
The differences are only on the created_at, update_at columns of all model tables:
- t.datetime "created_at"
- t.datetime "updated_at"
+ t.datetime "created_at", null: false
+ t.datetime "updated_at", null: false
I know that this is what it finds in the production db, but why were they created as null: false there and not in the development db too?
355
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.
The rails db:reset command will drop the database and set it up again. This is functionally equivalent to rails db:drop db:setup. This is not the same as running all the migrations. It will only use the contents of the current db/schema.rb or db/structure.sql file.
The format of the schema dump generated by Rails is controlled by the config.active_record.schema_format setting in config/application.rb. By default, the format is :ruby, but can also be set to :sql. If :ruby is selected, then the schema is stored in db/schema.rb.
While migrations may use execute to create database constructs that are not supported by the Ruby migration DSL, these constructs may not be able to be reconstituted by the schema dumper.
I had the same thing on my dev machine. Running db:drop in production is not a wise idea, but what will fix the 'problem':
rake db:drop db:create db:migrate
My mysql version had changed since I first created the database with rails. The migrations still ran according to the old mysql version.
This is what probabaly happens at your production environment.
131
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
