I'm new to ruby on rails, github and heroku. Now i am doing fixed deposit project in that project i am using database sqlite3 in my localhost and postgres in heroku.
I have add a field called int which datatype is string and i changed the datatype from string to integer. Finally, i decided to change it again from integer to float.
In my local host its working perfecly. But, when i'm trying to run in heroku it shows rake aborted.
heroku run rake db:migrate
it shows the following error message
Running `rake db:migrate` attached to terminal... up, run.4356
Connecting to database specified by DATABASE_URL
Migrating to CreateFds (20140505120047)
Migrating to Changedatatypeforfd (20140506065307)
Migrating to AddMdToFds (20140506080333)
Migrating to AddIntToFds (20140506080404)
Migrating to Changedatatypeforint (20140506103001)
== Changedatatypeforint: migrating ======================
-- change_column(:fds, :int, :integer)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PGError: ERROR: column "int" cannot be cast automatically to type integer
HINT: Specify a USING expression to perform the conversion.
: ALTER TABLE "fds" ALTER COLUMN "int" TYPE integer
my db files are listed below
20140506080404_add_int_to_fds.rb
class AddIntToFds < ActiveRecord::Migration
def change
add_column :fds, :int, :string
end
end
20140506103001_changedatatypeforint.rb
class Changedatatypeforint < ActiveRecord::Migration
def up
change_column :fds, :int, :integer
end
def down
change_column :fds, :int, :string
end
end
20140508105541_rechangedatatypeforint.rb
class Rechangedatatypeforint < ActiveRecord::Migration
def up
change_column :fds, :int, :float
end
def down
change_column :fds, :int, :integer
end
end
Sorry for my blunder.
Please give me the solution.
Thanks in advance.
Heroku uses PostgreSQL. In PostgreSQL int is a reserved word, you cannot use it as a column name.
Use something else for your int name
change_column :fds, :valid_name, :integer
SQL Key Words
If you want to cast from float to integer, one way to do it is:
class MigrationNameHere < ActiveRecord::Migration
def up
execute('ALTER TABLE fds ALTER COLUMN column_name TYPE integer USING round(column_name);')
end
end
This migration will convert all your float numbers to integer ones and it is not reversible so be careful. I advise you to have a backup before doing this.
Related
I have a currency(ccy) column on my event model and it's currently a string, I'd like to change it to a integer.
Although it works on my local environment, the following error was displayed when I try heroku run rake db:migrate to heroku.
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
PG::InvalidTextRepresentation: ERROR: invalid input syntax for integer: ""
: ALTER TABLE "events" ALTER COLUMN "ccy" TYPE integer USING CAST(ccy AS integer)
The migration file as below.
class ChangeCcyToEvents < ActiveRecord::Migration
def change
change_column :events, :ccy, 'integer USING CAST(ccy AS integer)'
end
end
I found the similar question PG::InvalidTextRepresentation: ERROR: invalid input syntax for integer: "M", so I changed migration file as below. But the result is the same.
class ChangeCcyToEvents < ActiveRecord::Migration
def change
Event.where(ccy: '').update_all(ccy: '')
change_column :events, :ccy, 'integer USING CAST(ccy AS integer)'
end
end
There is no value in all ccy column so far.
It would be appreciated if you could give me any advice.
Your migration is trying to convert a "" into an integer, which postgres complais about it (and it should, because it's not a valid conversion).
You should update your content for invalid cases before changing the column type:
class ChangeCcyToEvents < ActiveRecord::Migration
def up
Event.where("ccy IS NULL OR ccy = ''").update_all({ccy: '0'})
change_column :events, :ccy, 'integer USING CAST(ccy AS integer)'
end
def down
raise ActiveRecord::IrreversibleMigration
end
end
Perhaps is not complaining in development (localhost) because you're using a different version of postgreSQL than Heroku.
Next time, try using default values in migrations for this kind of columns.
So i made a migration like this
class AddDatetimeAttrToUsers < ActiveRecord::Migration
def change
change_column :users, :oauth_expires_at, :datetime
end
end
on my local environment it works just fine but when i try
heroku run rake db:migrate i get an error
ERROR: column "oauth_expires_at" cannot be cast automatically to type timestamp without time zone
HINT: Specify a USING expression to perform the conversion.
When i searched it, i created a new migration like this as best practice for changing an attribute using change.
class PutDatetimeFieldToUsersExpireAtColumn < ActiveRecord::Migration
def change
remove_column :users, :oauth_expires_at
add_column :users, :oauth_expires_at, :datetime
end
end
so i tried to use rake db:rollback to delete last migration and add this one informing me that the last migration is irreversible.
my question is, is there a way to actually rollback on an irreversible migration or should i just migrate using the new migration above?
In your example, you have the following migration file:
class AddDatetimeAttrToUsers < ActiveRecord::Migration
def change
change_column :users, :oauth_expires_at, :datetime
end
end
You have already run rake db:migrate successfully in your dev environment. You are running sqlite3 locally and PG on heroku, and and as a result, your change_column works locally, but it fails on PG because PG expects a 'using' statement.
The fix this, step 1 is to edit your migration file to add an up and down migration as suggested by Yohann above. Yes, you should do this even though you have already raked this migration.
class AddDatetimeAttrToUsers < ActiveRecord::Migration
def up
change_column :users, :oauth_expires_at, :datetime
end
def down
change_column :users, :oauth_expires_at, :time (or whatever type existed before datetime)
end
end
Now you can run rake db:rollback and avoid the irreversible migration error, but only if you HAVE NOT ADDED ADDITIONAL MIGRATIONS. If you have added additional migrations you will need to specify how far back to go using rake db:down VERSION=2018xxxxxxx or rake db:rollback STEP=X.
Now edit the migration so it plays nice with pg and sqlite3:
class AddDatetimeAttrToUsers < ActiveRecord::Migration
def up
change_column :users, :oauth_expires_at, :datetime, using: 'oauth_expires_at::datetime'
end
def down
change_column :users, :oauth_expires_at, :time
end
Now you should be able to rake db:migrate, push to heroku, and heroku run rake db:migrate and move on.
Finally, you should get pg working locally to match your production environment.
You can define up and down methods instead of change in your migration.
Here is an example:
def up
connection.execute %(create or replace view name_of_the_db_view)
end
def down
connection.execute %(drop view name_of_the_db_view)
end
With it you will be able to migrate and rollback the previously irreversible migration like it was a normal migration.
It seems you need to specify a current type of oauth_expires_at column, because at rollback Rails should know it to create the column. I mean following:
remove_column :users, :oauth_expires_at, :string
if you dare to lose your data on your local database then you can recover from irreversible migration(by losing your database data) by doing these steps:
1- first deleting your database(assuming that you are in the development environment and just ok to delete the database in this environment - your test database will also be gone)
export RAILS_ENV=development
rake db:drop
2- Reloading your schema file:
rake db:schema:load
3- To see your current migration files:
rake db:migrate:status
4- Delete the migration that you want to get rid of:
rake db:migrate:down VERSION=xxxxxx
rails destroy migration migration_name
5- Then you can make db:migrate to migrate your migrations.
rake db:migrate
I run:
rails generate migration AddHidemsgColumnToPublishers hide_msg:boolean
and the next file was created:
class AddHidemsgColumnToPublishers < ActiveRecord::Migration
def change
add_column :publishers, :hide_msg, :boolean
end
end
I want to set a default value into hide_msg by false.
so I tried:
rails generate migration add_default_value_to_hide_msg
class AddDefaultValueToHideMsg < ActiveRecord::Migration
def up
change_column :publishers, :hide_msg, :boolean, :default => false
end
def down
change_column :publishers, :hide_msg, :boolean, :default => nil
end
end
but I got errors:
rake db:migrate
== AddHidemsgColumnToPublishers: migrating ===================================
-- add_column(:publishers, :hide_msg, :boolean, {:default=>false})
rake aborted!
An error has occurred, this and all later migrations canceled:
PG::Error: ERROR: column "hide_msg" of relation "publishers" already exists
: ALTER TABLE "publishers" ADD COLUMN "hide_msg" boolean DEFAULT 'f'
Just a suggestion.... do not set the default value in the database, as you might face some problems if you want to change it latter on.
I think it is better if you set it in your model.
before_save :set_default_high_msg
def set_default_high_msg
self.high_msg ||= false
end
or even in your controller:
def new
#publisher = Publisher.new
#publisher.high_msg ||= false
...
end
rake db:migrate
== AddHidemsgColumnToPublishers: migrating ===================================
-- add_column(:publishers, :hide_msg, :boolean, {:default=>false})
Above thing means its trying to create colimn which already exist. If you check the class name AddHidemsgColumnToPublishers . This means it trying to execute your first migration in which you don't have default value. This clearly indicates you are doing something wrong.
publishers already has column hide_msg. So check the table description in db console. If you don't have any values in hide_msg then you can manually drop the column and re-run the rake db:migrate. Or you can keep that column as it is and just create migration to add default value.
change_column_default :publishers, :hide_msg, false
Doc: http://apidock.com/rails/ActiveRecord/ConnectionAdapters/SchemaStatements/change_column_default
I've got a problem trying to rollback one of my migration. It seems as if Rails is generating a temporary table for the migration, with temporary indices. My actual index on this table is less than 64 characters, but whenever Rails tries to create a temporary index for it, it turns into a name longer than 64 characters, and throws an error.
Here's my simple migration:
class AddColumnNameToPrices < ActiveRecord::Migration
def self.up
add_column :prices, :column_name, :decimal
end
def self.down
remove_column :prices, :column_name
end
end
Here's the error I'm getting:
== AddColumnNameToPrices: reverting ============================================
-- remove_column(:prices, :column_name)
rake aborted!
An error has occurred, this and all later migrations canceled:
Index name 'temp_index_altered_prices_on_column_and_other_column_and_third_column' on table 'altered_prices' is too long; the limit is 64 characters
I've changed the column names, but the example is still there. I can just make my change in a second migration, but that still means I can't rollback migrations on this table. I can rename the index in a new migration, but that still locks me out of this single migration.
Does anyone have ideas on how to get around this problem?
It looks like your database schema actually has index called prices_on_column_and_other_column_and_third_column. You have probably defined the index in your previous play with migrations. But than just removed index definition from migrations.
If it is true you have 2 options:
The simplier one (works if you code is not in production). You can
recreate database from scratch using migrations (not from
db/schema.rb) by calling rake db:drop db:create db:migrate. Make sure that you do not create this index with long name in other migration files. If you do, add :name => 'short_index_name' options to add_index call to make rails generate shorter name for the index.
If you experience this problem on a production database it is a bit more complicated. You might need to manually drop the index from the database console.
Had this problem today and fixed it by changing the migration to include the dropping and adding of the index causing the long name issue. This way the alteration is not tracked while I am altering the column type (that is where the really long name is caused)
I added the following:
class FixBadColumnTypeInNotifications < ActiveRecord::Migration
def change
# replace string ID with integer so it is Postgres friendly
remove_index :notifications, ["notifiable_id","notifiable_type"]
change_column :notifications, :notifiable_id, :integer
# shortened index name
add_index "notifications", ["notifiable_id","notifiable_type"], :name => "notifs_on_poly_id_and_type"
end
end
so my app was working fine. I created a new model and some associaitons, rendering all the old seed data in my heroku app useless. so I tried to reset it and populate it again. but I can't even migrate my db to heroku with the heroku rake db:migrate command. I'm using SQLite, but it seems my error is related to Postgres. I don't know what that means, if anything
Here is the error:
rake aborted!
An error has occurred, this and all later migrations canceled:
PGError: ERROR: column "to" cannot be cast to type "pg_catalog.int4"
: ALTER TABLE "emails" ALTER COLUMN "to" TYPE integer
Tasks: TOP => db:migrate
My migration:
class ChangeDataTypeForEmailUsers < ActiveRecord::Migration
def self.up
change_column :emails, :to, :integer
change_column :emails, :from, :integer
end
def self.down
change_column :to, :string
change_column :from, :string
end
end
What is the problem? My deployed app was working fine. I added a new model and figured I should reset the deployed database. So I ran heroku pg:reset then pushed my code to heroku. then tried to migrate the db, but it doesn't work! What have I done? I have been trying to figure this out for the last 4 hours. I can't think straight anymore. Any help would be greatly appreciated
Further to Hishalv's answer. If you can't use "change_column" then you can go the roundabout way:
def self.up
rename_column :emails, :to, :old_to
add_column :emails, :to, :integer
Email.reset_column_information
Email.all.each {|e| e.update_attribute(:to, e.old_to.to_i) }
remove_column :emails, :old_to
end
It's roundabout, and the Email.all.each might be slow - but it'll work and correctly cast for you.
If you're only going to use it on prod, then you might be able to replace the ruby-updates with a SQL UPDATE command that does the same thing in-database using a POSTGRES-specific cast method.
As per heroku docs here
Cause: PostgreSQL doesn’t know how to cast all the rows in that table to the specified type. Most likely it means you have an integer or a string in that column.
Solution: Inspect your records and make sure they can be converted to the new type. Sometimes it’s easier to just avoid using change_column, renaming/creating a new column instead.
I also was in this position before and i did not find a solution so i had to create a new column, postgresql seems to be sensitive when i comes to this issues. Hope it helps