I have strange problem with properly preparing test database in Rails3.
In schema.rb I have:
create_table "sites", :force => true do |t|
t.string "ldap_dn", :null => false
t.string "address"
t.string "phone"
t.string "description"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
then in one of my migrations I have:
change_column :sites, :id, :string, :limit => 255, :primary_key => true
Now, in development database after rake db:migrate I have
id VARCHAR(255) PK
BUT in test database after rake db:test:prepare I have
id INT(11) PK AI
In the log file (test.log) I can see all migrations are executed.
I use:
rails 3.2.13
mysql for both dev and test database
Is this some kind of bug?
Edit:
I meant development database. Sorry.
Check in your db/schema.rb what you have there. The rake tasks db:test:prepare (and db:test:load) just recreate the database from your schema file, which can become inconsistent with the schema_migrations table in certain cases (when you run migration and then change it during development).
If you have id defined as an INT in your schema and you have no pending migrations in your dev environment then you need to rerun your migration with rake db:migrate:redo.
You specifically say production database, so that makes me wonder if you ran the migrations in your development environment as well. Imho rake db:test:prepare creates a copy of your development database, so make you sure all your migrations have also run in development (we had a problem with that on our build machine, where there was no development database). To be sure that your test-database is created for the current schema, you could also use
RAILS_ENV=test rake db:reset
This will drop and recreate the database using the schema.rb file.
Related
So, say I have 10 models that have been evolving over the course of 100 migration files. Is there some sort of utility that could look my schema and build 10 'clean' migration files?
migration:
class CreateFoos < ActiveRecord::Migration
def change
create_table :foos do |t|
t.belongs_to :bar
t.string :baz
t.integer :qux, default: 0
end
add_index :foos, :bar_id
end
end
schema:
ActiveRecord::Schema.define(:version => 20140610225017) do
create_table "foos", :force => true do |t|
t.integer "bar_id"
t.string "baz"
t.integer "qux", :default => 0
end
add_index "foos", ["bar_id"], :name => "index_foos_on_bar_id"
end
I just feel like... if it knows how to go from the migration to the schema, then vice versa would be easy. Does this sound stupid?
I find you can delete your migrations after they have all been applied to all the databases, development through production. If you want to populate a new development or production database from scratch you can either (a) backup production and restore to the new database, or (b) load from the schema.rb file using rake db:schema:load.
If you really want the migrations for some documentation or clarity, create a new schema rails g migration schema2014. After the migration has been applied to production, delete all the old migrations files and copy schema.rb into the new migration.
If you don't care about the actual data and you're dealing with a new installation where you want to just create the DB structure using the schema.rb, you should use rake db:schema:load.
More details:
rake db:schema:load vs. migrations
Generate a migration file from schema.rb
I'm running into a LOT of problems just trying to do basic model generations and migrations in Rails 4 with Postgres. I have the pg gem installed, version 0.17.1.
In the beginning, I couldn't even run migrations without errors, because the schema_migrations table was created with the version column having a dimension of 1. Once I manually changed it to zero, it worked fine.
Now, if I look at all of the migrations that resulted from me using the Rails model generator, I see that every single column, with the exception of the id column in each table, was created with dimension of 1.
Is there some default setting I need to change? Is this somehow correct and I am messing up something else? This is my first Rails 4 project, so I'm just trying to figure out why it would want all of those columns to default to an Array.
Here is one of my migration files:
class CreateCatalogs < ActiveRecord::Migration
def change
create_table :catalogs do |t|
t.string :name
t.text :description
t.string :schema_name
t.string :catalog_type
t.boolean :billable
t.timestamps
end
end
end
And this is from schema.rb:
create_table "catalogs", force: true do |t|
t.string "name", array: true
t.text "description", array: true
t.string "schema_name", array: true
t.string "catalog_type", array: true
t.boolean "billable", array: true
t.datetime "created_at", array: true
t.datetime "updated_at", array: true
end
What in the heck!
As luck would have it, Ruby on Rails v4.0.3 was released today. I did the following:
Upgrade Rails
deleted db/migrate/schema.rb
Delete all 3 databases (dev, test, production)
ran rake db:setup
ran rake db:migrate
Looked at the new db/migrate/schema.rb to make sure it was OK
ran rake db:test:prepare
Sure enough, the problem is fixed in this new release. I couldn't find a record of the problem anywhere! It's been an issue for a few weeks. Anyway, fixed!
It may be your migration that specifies each column to be array
I have a db with columns (name, path). Now I have a migration file that changes the columns to be (name, pathorig, pathjson, scramble).
Doing rake db:reset and rake db:migrate doesn't update the table. Why can this happen?
my migration file:
class CreateUploads < ActiveRecord::Migration
def change
create_table :uploads do |t|
t.string :name
t.string :pathorig
t.string :pathjson
t.string :scramble
t.timestamps
end
end
end
The schema.rb file:
ActiveRecord::Schema.define(version: 20131029072745) do
create_table "uploads", force: true do |t|
t.string "name"
t.string "path"
t.datetime "created_at"
t.datetime "updated_at"
end
end
Difference between rake db:migrate db:reset and db:schema:load has a great explanation of what the various rake db:* commands do.
Because rake db:reset performs a db:schema:load, it's loading the old columns from your table, rather than calling db:migrate, this is why your migration isn't being run.
Consider writing a migration that changes the names of those columns, rather than re-creates an existing table, or manually run rake db:drop; rake db:create db:migrate
For Rails 3.2 I have written this migration to rename the column name as seen in the migration
class RenameKpiColumn < ActiveRecord::Migration
def change
rename_column(:key_performance_intervals, :kpi_id, :key_performance_interval_id)
end
end
And then I said bundle exec rails db:migrate
If I go to Schema.rb I see this for that table, so looks likes it picked the new column name from Migration:
create_table "key_performance_intervals", :force => true do |t|
t.integer "key_performance_interval_id"
t.integer "interval"
t.integer "interval_unit"
t.decimal "count"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
But if I open the pgAdmin tool and look at the tables and column names in there, it is still using the old column name of kip_id .
Is there any step I am missing?
Since migrating the database gives no output, it seems that the migrations ran fine. Just restart pAdmin and the changes should be reflected there.
To also prepare your test database, run
$ rake db:test:prepare
Am I correct in saying that the db/schema.rb file should be pulling from the db/migrate files on rake db:migrate? I am running a rake db:migrate and it is adding a table that isn't defined in the migrate, nor the models. Any ideas?
Migrate Files (just one):
class CreateUsers < ActiveRecord::Migration
def change
create_table :users do |t|
t.string :email
t.string :hashed_password
t.timestamps
end
end
end
Resulting Schema after rake:
ActiveRecord::Schema.define(:version => 20121113214159) do
create_table "user_categories", :force => true do |t|
t.string "title"
t.string "description"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
create_table "users", :force => true do |t|
t.string "email"
t.string "hashed_password"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
end
I had added a user_categories scaffolding earlier, but incorrectly so I destroyed it. Not sure where I went wrong in destroying parts...
If you don't have any important data on your db, you could run rake db:drop then rake db:create. Then run rake db:migrate and it should update your schema clean.
It's important to note that rake db:migrate will poll your database for its current state (separate of migrations) and update schema.rb accordingly. If you go into SQL command line and add a table, for example, and then run rake db:migrate, schema.rb will reflect that new table whether there's a migration or not.
Could be that your forgot to define environment variables.
Open Gemfile and verify that you don't use the sqlite gem for your environment
Type the rake db:drop then rake db:drop commands if as output you receive empty string probably you forgot to setup environment variables
Checkout the config/database.yml file and find places where you could use them. You should find something like that: database: <%= ENV["<DB_NAME"] %>
Ensure that your variables has been set before. If you use the dotenv or figaro gems, probably you forgot to create appropriate file or define variables there