I'm working on a gift registry app using rails 3.0. The app allows multiple guests to contribute towards a gift. When displaying the gifts I need to show the amount remaining, and if the total amount has been given I needs to show the item as purchased.
For performance I want to de-normalize the sum of the total contributions, and the status of the item.
Seems simple enough, but as I tried to figure out how to put this in the model in a way that is completely encapsulated, and works in all circumstances, things got much more complicated then I expected.
I tried a few different approaches including a callback on the association between item and contribution, but ultimately ended up with a callback on the contribution object.
item.rb
class Item < ActiveRecord::Base
# decimal amount
# decimal total_contributed
# boolean purchased
has_many :contributions, :inverse_of => :item
def set_total_contributed
self.total_contributed = 0
contributions.each do |cont|
self.total_contributed += cont.amount
end
purchased = self.total_contributed >= amount
end
end
order.rb
class Order < ActiveRecord::Base
has_many :contributions, :inverse_of => :order, :dependent => :destroy
end
contribution.rb
class Contribution < ActiveRecord::Base
belongs_to :item, :inverse_of => :contributions
belongs_to :order, :inverse_of => :contributions
after_create do |cont|
item.set_total_contributed
item.save
end
after_destroy do |cont|
item.contributions.delete(cont)
item.set_total_contributed
item.save
end
end
This appears to work in the situations I need it to, but it doesn't feel right.
First, the fact that I have to manually update the contributions association in the destroy callback seems odd.
Also, the de-normalized values are only properly updated when objects are persisted.
So the question is, how can I do this better and what's the best practice for this kind of scenario?
Related
Let have Order and Item models.
class Order < ApplicationRecord
has_many :items, inverse_of: :order, dependent: :delete_all
before_save do
self.packed_volume = compute_packed_volume
end
private
def compute_packed_volume
items.count * 0.1O
end
end
And
class Item < ApplicationRecord
belongs_to :order, inverse_of: :items
end
The problem is that items.count is equals to 0 since items are not yet created.
How can we get the number of items that will be created to used it when we create an order?
Try size instead, it won't run a query
items.size * 0.1O
Hope that helps!
What you're looking for is a "counter cache". It implements exactly what you're trying to do. ActiveRecord can do this for you:
belongs_to :post, :counter_cache => true
There are a couple of gems that do this, updating a count field in the parent record whenever a child record is created or deleted.
Gem counter-cache does the job simply. Another, counter-culture takes it a bit further, including support for counting children in has_many :through relationships.
Your example is a little more interesting, as you're not looking for the count, but a computation on the count. So, you could either just roll with that and use it to compute the packed_volume on the fly, probably in a method on the model very similar to your compute_packed_volume() method.
If you wanted to store the actual volume in your parent record (perhaps it is very expensive to compute), you need to shift from putting callbacks on the parent model to putting them on the child model. The counter_culture gem supports that with its "Delta Magnitude". Something like this:
class Item < ActiveRecord::Base
belongs_to :order
counter_culture :order, column_name: :packed_volume, delta_magnitude: 0.1
end
class Order < ActiveRecord::Base
has_many :items
end
The delta_magnitude parameter can take a proc, so you can do more complicated things. Perhaps something like this:
counter_culture :order, column_name: :packed_volume, delta_magnitude: -> {|item| item.length * item.width * item.height }
You could roll your own solution along these lines if you have other requirements that preclude using a gem. You'll need to add callbacks to Item for after_create and before_destroy to increment/decrement the parent record. You may also need to update the order when the record is changed, if your volume computation becomes more complicated.
I'm a rails begginer and I was coding a simple app to train the language and other stuff.
In my app, I have three different scaffolds generated, one for People, one for House Activities and one last to link them together called Assignments. It's a many to many dependency situation.
So I was trying to calculate the total time a person would have to spend doing all the house activities assigned to them and store it inside the Person in an attribute called "time_allocated". So if I have two activities assigned to someone, it would return the sum of the duration of those activities.
After searching I discovered that creating an attribute with three dependencies is no good, but I don't know how to do it other way.
These are the models and the things that I tried to do:
Person Model
class Person < ActiveRecord::Base
has_many :assignments, dependent: :destroy
has_many :house_activities, through: :assignments
extend FriendlyId
friendly_id :name, use: :slugged
end
House Activity Model
class HouseActivity < ActiveRecord::Base
has_many :assignments, dependent: :destroy
has_many :people, through: :assignments
extend FriendlyId
friendly_id :name, use: :slugged
end
Assignment Model
class Assignment < ActiveRecord::Base
belongs_to :person
belongs_to :house_activity
def self.time_allocation #fulltime
Assignment.all.each do |assignment|
if (assignment.person.time_allocation.present?)
assignment.person.time_allocation += assignment.house_activity.duration
else
assignment.person.time_allocation = assignment.house_activity.duration
end
end
end
end
If I understand correctly, you're trying to get the sum of the durations of all of a Person's house_activities. You can get this directly from the database using Rails' ActiveRecord::Calculations#sum method:
person = Person.find(123)
puts person.house_activities.sum(:duration)
# => 500
Of course, you could create a helper method for this as well:
class Person < ActiveRecord::Base
# ...
def total_activities_duration
house_activities.sum(:duration)
end
end
person = Person.find(123)
puts person.total_activities_duration
# => 500
I would advise against storing this sum in the database, because then you have to ensure its consistency (e.g. every time an Assignment is created, edited, or deleted, you have to ensure that the associated Person is updated with the new sum). You might think that calculating the sum anew every time will slow down your app, and it may at some time in the future when you have thousands of records, but there's no need to optimize this unless and until an actual performance problem arises.
I'm working on a Rails app (Ruby 1.9.2 / Rails 3.0.3) that keeps track of people and their memberships to different teams over time. I'm having trouble coming up with a scalable way to combine duplicate Person objects. By 'combine' I mean to delete all but one of the duplicate Person objects and update all references to point to the remaining copy of that Person. Here's some code:
Models:
Person.rb
class Person < ActiveRecord::Base
has_many :rostered_people, :dependent => :destroy
has_many :rosters, :through => :rostered_people
has_many :crews, :through => :rosters
def crew(year = Time.now.year)
all_rosters = RosteredPerson.find_all_by_person_id(id).collect {|t| t.roster_id}
r = Roster.find_by_id_and_year(all_rosters, year)
r and r.crew
end
end
Crew.rb
class Crew < ActiveRecord::Base
has_many :rosters
has_many :people, :through => :rosters
end
Roster.rb
class Roster < ActiveRecord::Base
has_many :rostered_people, :dependent => :destroy
has_many :people, :through => :rostered_people
belongs_to :crew
end
RosteredPerson.rb
class RosteredPerson < ActiveRecord::Base
belongs_to :roster
belongs_to :person
end
Person objects can be created with just a first and last name, but they have one truly unique field called iqcs_num (think of it like a social security number) which can be optionally stored on either the create or update actions.
So within the create and update actions, I would like to implement a check for duplicate Person objects, delete the duplicates, then update all of the crew and roster references to point to the remaining Person.
Would it be safe to use .update_all on each model? That seems kind of brute force, especially since I will probably add more models in the future that depend on Person and I don't want to have to remember to maintain the find_duplicate function.
Thanks for the help!
The 'scalable' way to deal with this is to make the de-duplication process part of the app's normal function - whenever you save a record, make sure it's not a duplicate. You can do this by adding a callback to the Person model. Perhaps something like this:
before_save :check_for_duplicate
def check_for_duplicate
if iqcs_num
dup = Person.find_by_iqcs_num(self.iqcs_num)
if dup && dup.id != self.id
# move associated objects to existing record
dup.crews = dup.crews + self.crews
# update existing record
dup.update_attributes(:name => self.name, :other_field => self.other_field)
# delete this record
self.destroy
# return false, so that no other callbacks get triggered
return false
end
end
end
You'll want to make sure that you index the table you store Person objects in on the iqcs_num column, so that this lookup stays efficient as the number of records grows - it's going to be performed every time you update a Person record, after all.
I don't know that you can get out of keeping the callback up-to-date - it's entirely likely that different sorts of associated objects will have to be moved differently. On the other hand, it only exists in one place, and it's the same place you'd be adding the associations anyway - in the model.
Finally, to make sure your code is working, you'll probably want to add a validation on the Person model that prevents duplicates from existing. Something like:
validates :iqcs_num, :uniqueness => true, :allow_nil => true
Each User can have many Resources, and each of those Resources has many Votes, and each of those votes have a value attribute that I want to sum all that particular users resources.
If I were to type this in a syntactically incorrect way I want something like...
#user.resources.votes.sum(&:value), but that obviously won't work.
I believe I need to use collect but I am not sure?
This is the closest I got but it prints them out, heh
<%= #user.resources.collect { |r| r.votes.sum(&:value) } %>
I'd recommend setting up a has_many :through relationship between the User and Vote objects. Set the models up like this:
class User < ActiveRecord::Base
has_many :resources
has_many :votes, :through => :resources
end
class Resource < ActiveRecord::Base
belongs_to :user
has_many :votes
end
class Vote < ActiveRecord::Base
belongs_to :resource
end
Once this is done you can simply call user.votes and do whatever you want with that collection.
For more info on has_many :through relations, see this guide: http://guides.rubyonrails.org/association_basics.html#the-has_many-through-association
How can you tell who voted having a Vote instance? Your Vote model has to have voter_id field and additional association:
# in Vote.rb
belongs_to :voter, class_name: 'User', foreign_key: 'voter_id'
And in your User model:
# in User.rb
has_may :submited_votes, class_name: 'Vote', foreign_key: 'voter_id'
So, #user.votes (as David Underwood proposed) will give you #user resources' votes. And #user.submited_votes will give you votes submitted by the #user.
Using just User <- Resource <- Vote relation won't allow you to separate some user's votes made by him and votes made for its resources.
For a total sum this should work or something real close.
sum = 0
#user.resources.each do |r|
r.votes.each do |v|
sum += v.value
end
end
This might work for you:
#user.resources.map {|r| r.votes.sum(:value)}.sum
How many records do you have, there is a way to push this to the database level I believe, I would have to check, but if it is only a few records then doing this in ruby would probably be ok
Try this code
#user.resources.map(&:votes).flatten.map(&:value).sum
Relationships
class Promotion < ActiveRecord::Base
has_many :promotion_sweepstakes,
has_many :sweepstakes,
:through => :promotion_sweepstakes
end
class PromotionSweepstake < ActiveRecord::Base
belongs_to :promotion
belongs_to :sweepstake
end
class Sweepstake < ActiveRecord::Base
# Not relevant in this question, but I included the class
end
So a Promotion has_many Sweepstake through join table PromotionSweepstake. This is a legacy db schema so the naming might seem a bit odd and there are some self.table_name == and foreign_key stuff left out.
The nature of this app demands that at least one entry in the join table is present for a promotionId, because not having a sweepstake would break the app.
First question
How can I guarantee that there is always one entry in PromotionSweepstake for a Promotion? At least one Sweepstake.id has to be included upon creation, and once an entry in the join table is created there has to be a minimum of one for each Promotion/promotion_id.
Second question (other option)
If the previous suggestion would not be possible, which I doubt is true, there's another way the problem can be worked around. There's a sort of "default Sweepstake" with a certain id. If through a form all the sweepstake_ids would be removed (so that all entries for the Promotion in the join table would be deleted), can I create a new entry in PromotionSweepstake?
pseudo_code (sort of)
delete promotion_sweepstake with ids [1, 4, 5] where promotion_id = 1
if promotion with id=1 has no promotion_sweepstakes
add promotion_sweepstake with promotion_id 1 and sweepstake_id 100
end
Thank you for your help.
A presence validation should solve the problem in case of creation and modification of Promotions.
class Promotion < ActiveRecord::Base
has_many :promotion_sweepstakes
has_many :sweepstakes,
:through => :promotion_sweepstakes
validates :sweepstakes, :presence => true
end
In order to assure consistency when there's an attempt to delete or update a Sweepstake or a PromotionSweepstake you'd have to write your own validations for those two classes. They would have to check whether previously referenced Promotions are still valid, i.e. still have some Sweepstakes.
A simple solution would take and advantage of validates :sweepstakes, :presence => true in Promotion. After updating referenced PromotionSweepstakes or Sweepstakes in a transaction you would have to call Promotion#valid? on previously referenced Promotions. If they're not valid you roll back the transaction as the modification broke the consistency.
Alternatively you could use before_destroy in both PromotionSweepstake and Sweepstake in order to prevent changes violating your consistency requirements.
class PromotionSweepstake < ActiveRecord::Base
belongs_to :promotion
belongs_to :sweepstake
before_destroy :check_for_promotion_on_destroy
private
def check_for_promotion_on_destroy
raise 'deleting the last sweepstake' if promotion.sweepstakes.count == 1
end
end
class Sweepstake < ActiveRecord::Base
has_many :promotion_sweepstakes
has_many :promotions, :through => :promotion_sweepstakes
before_destroy :check_for_promotions_on_destroy
private
def check_for_promotions_on_destroy
promotions.each do |prom|
raise 'deleting the last sweepstake' if prom.sweepstakes.count == 1
end
end
end