I have added monetize and demonetize helpers inside ActiveRecord::Migration, ActiveRecord::ConnectionAdapters::TableDefinition and ActiveRecord::ConnectionAdapters::Table by that pull request.
That file shows usage examples. So you will understand invented changes at glance. (It works)
But I have no idea how to test my helpers. What way can I write specs for them? All my attempts of writing migrations in spec files and running them manually failed. Migration manual run did not change table (or I was unable to detect changes) and did not throw any exception.
Example of my attempt:
describe 'monetize' do
class MonetizeMigration < ActiveRecord::Migration
def change
create_table :items
monetize :items, :price
end
end
class Item < ActiveRecord::Base; end
it 'should monetize items' do
MonetizeMigration.up #=> nil
Item #=> Item(has no table)
end
end
This worked for me in the console:
[4667]foo#bar:~/dev/ror/foo$ rails c
Loading development environment (Rails 3.2.9)
irb(main):001:0> class MyMigration def change
irb(main):003:2> create_table :foo
irb(main):004:2> end
irb(main):005:1> end
=> nil
irb(main):006:0> MyMigration.new.change
-- create_table(:foo)
(4.5ms) select sqlite_version(*)
(133.2ms) CREATE TABLE "foo" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL)
-> 0.2362s
=> []
You can execute any migration helper methods right on your database connection:
ActiveRecord::Base.connection.create_table :items
Thanks to #happy_user for showing my mistake in first attempt. I think someone may use my latest solution in the future, so I'll leave it here.
Related
I am using Ruby Workflow in my ActiveRecords using Gem: Workflow
Existing Running Code contains:
I am having an ActiveRecord: X
I am having two Migrations already:
(Ref1) CreateX migration (which creates table X)
(Ref2) CreateInitialEntryInX migration (which creates one entry in table X)
New Changes:
Now I wanted to add workflow in ActiveRecord X, hence I did:
(Ref3) I added the workflow code in ActiveRecord Model X (mentioning :status as my workflow field)
(Ref4) AddStatusFieldToX migration (which adds :status field in table X)
Now when I run rake db:migrate after the changes, the (Ref2) breaks cos Migration looks for :status field as it is mentioned in ActiveRecord Model in the Workflow section, but :status field has not been added yet as migration (Ref4) has not executed yet.
Hence, all the builds fail when all migrations are run in sequence, Any solution to this?
I do not want to resequence any of the migration or edit any old existing migrations.
My Model looks like:
class BaseModel < ActiveRecord::Base
#
# Workflow to define states of Role
#
# Initial State => Active
#
# # State Diagram::
# Active --soft_delete--> Deleted
# Deleted
#
# * activate, soft_delete are the event which triggers the state transition
#
include Workflow
workflow_column :status
workflow do
state :active, X_MODEL_STATES::ACTIVE do
event :soft_delete, transitions_to: :deleted
end
state :deleted, X_MODEL_STATES::DELETED
on_transition do |from, to, event, *event_args|
self.update_attribute(:status, to)
end
end
def trigger_event(event)
begin
case event.to_i
when X_MODEL_EVENTS::ACTIVATE
self.activate!
when X_MODEL_EVENTS::SOFT_DELETE
self.soft_delete!
end
rescue ....
end
end
class X_MODEL_STATES
ACTIVE = 1
DELETED = 2
end
class X_MODEL_EVENTS
ACTIVATE = 1
SOFT_DELETE = 2
end
# Migrations(posting Up functions only - in correct sequence)
#--------------------------------------------------
#1st: Migration - This is already existing migration
CreateX < ActiveRecord::Migration
def up
create_table :xs do |t|
t.string :name
t.timestamps null: false
end
end
end
#2nd: Migration - This is already existing migration
CreateInitialX < ActiveRecord::Migration
def up
X.create({:name => 'Kartik'})
end
end
#3rd: Migration - This is a new migration
AddStatusToX < ActiveRecord::Migration
def up
add_column :xs, :status, :integer
x.all.each do |x_instance|
x.status = X_MODEL_STATES::ACTIVE
x.save!
end
end
end
So, when Migration#2 runs, it tries to find :status field to write is with initial value of X_MODEL_STATES::ACTIVE as it is mentioned in Active Record Model files workflow as: workflow_column :status and does not find the field as Migration#3 is yet to execute.
You can wrap up your workflow code by a check for column_name.
if self.attribute_names.include?('status')
include Workflow
workflow_column :status
workflow do
...
end
end
This will result in running workflow code only after 'AddStatusToTable' migration ran successfully.
This is a pain, as your models need to be consistent for migrations. I don't know any auto solutions for this.
Theoreticaly the best way would be to have model code versions binded with migrations. But I don't know any system that allows this.
Every time I do big models refactoring i experience this problem. Possible solutions to this situation.
Run migrations on production manually to assure consitent state between migrations and models
Temporarily comment out workflow code in model to run blocking migration, then deploy, then uncomment workflow code and move on with deploy and next migrations
Version migrations and model changes on branches, so they are consistent. Deploy to production and run migration by chunks
Include temp workarounds in the model code, and remove them from source after migrations on production are deployed.
Monkey-patch model in migration code for backwards compatibility. In your situation this would be to dynamically remove 'workflow' from model code, which might be hard, and then run migration
All solutions are some kind of dirty hacks, but it's not easy to have migrations and model code versioned. The best way would be to deploy in chunks or if need to deploy all at once use some temp code in model and remove it after deploy on production.
THANKS ALL
I found the solution to this, and i am posting it here. The problems to issue here were:
Add :status field to ActiveRecord Model X without commenting out Workflow Code and not let Workflow disallow creation of an instance in Table X during migration.
Secondly, add an if condition to it as specified by #007sumit.
Thirdly, to be able to reload Model in migration with the updated column_information of Model X
Writing whole code solution here:
class BaseModel < ActiveRecord::Base
#
# Workflow to define states of Role
#
# Initial State => Active
#
# # State Diagram::
# Active --soft_delete--> Deleted
# Deleted
#
# * activate, soft_delete are the event which triggers the state transition
#
# if condition to add workflow only if :status field is added
if self.attribute_names.include?('status')
include Workflow
workflow_column :status
workflow do
state :active, X_MODEL_STATES::ACTIVE do
event :soft_delete, transitions_to: :deleted
end
state :deleted, X_MODEL_STATES::DELETED
end
end
def trigger_event(event)
...
end
end
class X_MODEL_STATES
...
end
class X_MODEL_EVENTS
...
end
# Migrations(posting Up functions only - in correct sequence)
#--------------------------------------------------
#1st: Migration - This is already existing migration
CreateX < ActiveRecord::Migration
def up
create_table :xs do |t|
t.string :name
t.timestamps null: false
end
end
end
#2nd: Migration - This is already existing migration
CreateInitialX < ActiveRecord::Migration
def up
X.create({:name => 'Kartik'})
end
end
#3rd: Migration - This is a new migration to add status field and
# modify status value in existing entries in X Model
AddStatusToX < ActiveRecord::Migration
def up
add_column :xs, :status, :integer
# This resets Model Class before executing this migration and
# Workflow is identified from the if condition specified which was
# being skipped previously without this line as Model Class is
# loaded only once before all migrations run.
# Thanks to post: http://stackoverflow.com/questions/200813/how-do-i-force-activerecord-to-reload-a-class
x.reset_column_information
x.all.each do |x_instance|
x.status = X_MODEL_STATES::ACTIVE
x.save!
end
end
end
#stan-brajewski Now, this code can go in one deployment.
Thanks all for inputs :)
I'm adding a counter_cache, and my migrate is getting an error.
def up
add_column :benefits, :benefit_rows_count, :integer, :default => 0
Benefit.reset_column_information
Benefit.find(:all).each do |b|
Benefit.update_counters b.id, :benefit_rows_count => b.benefit_rows.length
end
end
SQL:
UPDATE "benefits" SET "benefit_rows_count" = COALESCE("benefit_rows_count", 0) + 0
WHERE "benefits"."id" IN (SELECT "benefits"."id"
FROM "benefits"
WHERE "benefits"."id" = 1
ORDER BY benefit_types.position, benefit_types.name, id)
This ORDER BY, inside the update is because of the default_scope, and it fails the migration.
Unfortunately, when i update the record, i get the same error when the callback update_counters is executed. I've read some posts that said default_scope should be avoided. I checked Rails 4 source code (i'm using Rails 3) and update_counters has not been fixed. I'm going to reopen ActiveRecord::CounterCache.update_counters and try to unscope it.
As already noted, your default scopes are tripping you up. There's a better way to avoid this sort of issue in your migrations: redefine your model in the scope of the migration:
class MigrateFooToBar < ActiveRecord::Migration
class Foo < ActiveRecord::Base; end
def up
# ...
end
end
When you then reference Foo from within up you reference the void-of-restrictions-and-default-scopes MigrateFooToBar::Foo which keeps you migrations from A) having to know too much about your models and B) confusing everybody else on your team when they run your migrations.
Thx Baldrick, i'm new to rails. And unscoped worked:
Benefit.unscoped.update_counters b.id, :benefit_rows_count => b.benefit_rows.length
Sometimes, data migrations are required. As time passes, code changes and migrations using your domain model are no longer valid and migrations fail. What are the best practices for migrating data?
I tried make an example to clarify the problem:
Consider this. You have a migration
class ChangeFromPartnerAppliedToAppliedAt < ActiveRecord::Migration
def up
User.all.each do |user|
user.applied_at = user.partner_application_at
user.save
end
end
this runs perfectly fine, of course. Later, you need a schema change
class AddAcceptanceConfirmedAt < ActiveRecord::Migration
def change
add_column :users, :acceptance_confirmed_at, :datetime
end
end
class User < ActiveRecord::Base
before_save :do_something_with_acceptance_confirmed_at
end
For you, no problem. It runs perfectly. But if your coworker pulls both these today, not having run the first migration yet, he'll get this error on running the first migration:
rake aborted!
An error has occurred, this and all later migrations canceled:
undefined method `acceptance_confirmed_at=' for #<User:0x007f85902346d8>
That's not being a team player, he'll be fixing the bug you introduced. What should you have done?
This is a perfect example of the Using Models in Your Migrations
class ChangeFromPartnerAppliedToAppliedAt < ActiveRecord::Migration
class User < ActiveRecord::Base
end
def up
User.all.each do |user|
user.applied_at = user.partner_application_at
user.save
end
end
Edited after Mischa's comment
class ChangeFromPartnerAppliedToAppliedAt < ActiveRecord::Migration
class User < ActiveRecord::Base
end
def up
User.update_all('applied_at = partner_application_at')
end
end
Best practice is: don't use models in migrations. Migrations change the way AR maps, so do not use them at all. Do it all with SQL. This way it will always work.
This:
User.all.each do |user|
user.applied_at = user.partner_application_at
user.save
end
I would do like this
update "UPDATE users SET applied_at=partner_application_at"
Some times 'migrating data' could not be performed as a part of schema migration, like discussed above. Sometimes 'migrating data' means 'fix historical data inconstancies' or 'update your Solr/Elasticsearch' index, so its a complex task. For these kind of tasks, check out this gem https://github.com/OffgridElectric/rails-data-migrations
This gem was designed to decouple Rails schema migrations from data migrations, so it wont cause downtimes at deploy time and make it easy to manage in overall
I have model with tag context:
class Product < ActiveRecord::Base
acts_as_taggable_on :categories
end
I'm trying to initialize tags caching:
class AddCachedCategoryListToProducts < ActiveRecord::Migration
def self.up
add_column :products, :cached_category_list, :string
Product.reset_column_information
products = Product.all
products.each { |p| p.save_cached_tag_list }
end
end
But cached_category_list does not initializing. What I'm doing wrong? Does anybody can use caching with this gem (my version is 2.0.6)?
Well, today I had the same problem.
I finally solved it, and my migration cached the desired tags.
The problem with your migration was two-fold:
The ActsAsTaggable code which sets up caching needs to run again after the column information is reset. Otherwise, the caching methods are not created (see https://github.com/mbleigh/acts-as-taggable-on/blob/v2.0.6/lib/acts_as_taggable_on/acts_as_taggable_on/cache.rb)
The method you are calling, save_cached_tag_list, does NOT automatically save the record, as it is installed as a before_save hook, and it doesn't want to create an infinite loop. So you must call save.
So, try replacing your migration with the following, and it should work:
class AddCachedCategoryListToProducts < ActiveRecord::Migration
def self.up
add_column :products, :cached_category_list, :string
Product.reset_column_information
# next line makes ActsAsTaggableOn see the new column and create cache methods
ActsAsTaggableOn::Taggable::Cache.included(Product)
Product.find_each(:batch_size => 1000) do |p|
p.category_list # it seems you need to do this first to generate the list
p.save! # you were missing the save line!
end
end
end
That should do it.
If you are using this in combination with owned tags, that might be the problem.
Looking at the code of the gem, it seems that the caching of owned tags isn't support
Hope this helps,
Best,
J
I'd like to know which is the preferred way to add records to a database table in a Rails Migration. I've read on Ola Bini's book (Jruby on Rails) that he does something like this:
class CreateProductCategories < ActiveRecord::Migration
#defines the AR class
class ProductType < ActiveRecord::Base; end
def self.up
#CREATE THE TABLES...
load_data
end
def self.load_data
#Use AR object to create default data
ProductType.create(:name => "type")
end
end
This is nice and clean but for some reason, doesn't work on the lasts versions of rails...
The question is, how do you populate the database with default data (like users or something)?
Thanks!
The Rails API documentation for migrations shows a simpler way to achieve this.
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
class CreateProductCategories < ActiveRecord::Migration
def self.up
create_table "product_categories" do |t|
t.string name
# etc.
end
# Now populate the category list with default data
ProductCategory.create :name => 'Books', ...
ProductCategory.create :name => 'Games', ... # Etc.
# The "down" method takes care of the data because it
# drops the whole table.
end
def self.down
drop_table "product_categories"
end
end
Tested on Rails 2.3.0, but this should work for many earlier versions too.
You could use fixtures for that. It means having a yaml file somewhere with the data you want to insert.
Here is a changeset I committed for this in one of my app:
db/migrate/004_load_profiles.rb
require 'active_record/fixtures'
class LoadProfiles < ActiveRecord::Migration
def self.up
down()
directory = File.join(File.dirname(__FILE__), "init_data")
Fixtures.create_fixtures(directory, "profiles")
end
def self.down
Profile.delete_all
end
end
db/migrate/init_data/profiles.yaml
admin:
name: Admin
value: 1
normal:
name: Normal user
value: 2
You could also define in your seeds.rb file, for instance:
Grid.create :ref_code => 'one' , :name => 'Grade Única'
and after run:
rake db:seed
your migrations have access to all your models, so you shouldn't be creating a class inside the migration.
I am using the latest rails, and I can confirm that the example you posted definitely OUGHT to work.
However, migrations are a special beast. As long as you are clear, I don't see anything wrong with an ActiveRecord::Base.connection.execute("INSERT INTO product_types (name) VALUES ('type1'), ('type2')").
The advantage to this is, you can easily generate it by using some kind of GUI or web front-end to populate your starting data, and then doing a mysqldump -uroot database_name.product_types.
Whatever makes things easiest for the kind of person who's going to be executing your migrations and maintaining the product.
You should really not use
ProductType.create
in your migrations.
I have done similar but in the long run they are not guaranteed to work.
When you run the migration the model class you are using is the one at the time you run the migration, not the one at the time you created the migration. You will have to be sure you never change your model in such a way to stop you migration from running.
You are much better off running SQL for example:
[{name: 'Type', ..}, .. ].each do |type|
execute("INSERT INTO product_types (name) VALUES ('#{type[:name]} .. )
end