For example, I have three model user, question and answer, and the relationship between them are:
class User < ActiveRecord::Base
has_many :answers
has_many :questions
end
class Question < ActiveRecord::Base
has_many :answers, :dependent => :destroy
belongs_to :user, :counter_cache => true
end
class Answer < ActiveRecord::Base
belongs_to :user, :counter_cache => true
belongs_to :question, :counter_cache => true
end
Then when i want to destroy a question(with 1000 answers), these will happen:
The answers will destroy one by one and will update the counter in the user model, even the counter in the question i want to destroy, and which will take a long time to do the counter update.
my question is how to make it faster?
I got my own solution like this:
step 1:
remove the dependent destroy, which will call for counter update before destroy itself.
step 2:
add my own before_destroy, like this
before_destroy :delete_dependents
and use delete_all function to delete without call any before_destroy, then call reset_counters function to reset the counter in User model.
full codes of class question:
class Question < ActiveRecord::Base
has_many :answers
has_many :answer_users, :through => :answers, :source => :user, :uniq => true
belongs_to :user, :counter_cache => true
before_destroy :delete_dependents
private
def delete_dependents
answer_user_ids = self.answer_user_ids # eager loading for store the answer users id
Answer.delete_all(:question_id => self.id)
answer_user_ids.each do |u_id|
User.reset_counters u_id, :answers
end
end
end
PS: If there are too many counters need to be reset, you might need a background job to work it out.
Related
In my Game model, I have
class Game < ApplicationRecord
has_many :assignments
has_many :users, through: :assignments
accepts_nested_attributes_for :assignments
after_create :create_assignments
def create_assignments
3.times { Assignment.create!(game_id: id, user_id: 1) }
end
end
This works but I need the user_id to be blank when it's created (it will be edited at a later time). It won't create assignments unless there is a user_id with a value.
I've tried leaving it blank and omitting it, but that doesn't work. I think I need to put optional: true somewhere but I'm pretty stumped on this one.
Needed to add :optional => true on Assignment Model
class Assignment < ApplicationRecord
belongs_to :game
belongs_to :user, :optional => true
end
I have a hierarchy of models, for which I'm trying to cascade a :touch event.
class Category < ActiveRecord::Base
has_many :posts
after_touch :do_stuff
def do_stuff
# do stuff...
end
end
class Post < ActiveRecord::Base
belongs_to :category, :touch => true
has_many :comments, :dependent => :destroy
end
class Comment < ActiveRecord::Base
belongs_to :post, :touch => true
end
I have a form for Post which creates a new Comment through nesteed_attributes. When this event occurs the after_touch method on the Category class is fired 4 times in quick succession (milliseconds apart) and I'm at a bit of a loss to understand why.
In my minds-eye the callback should only be fired once for the transaction? I also notice that in events such as destroying a post the callback is fired for the post, and each of the comments which is destroyed, resulting in many-many calls.
Is this normal behaviour? Is it expected? Is there a way around this? Is this a bug in Rails?
class Category < ActiveRecord::Base
has_many :posts
after_touch :do_stuff
def do_stuff
# do stuff...
end
end
class Post < ActiveRecord::Base
belongs_to :category
has_many :comments, :dependent => :destroy
end
class Comment < ActiveRecord::Base
belongs_to :post
end
posts_controller
def update
...
if #post.update
#post.category.touch
else
...
end
end
Seems that this is 'by design' within Rails at the moment. There also doesn't seem to be any immediate plan to change this, so for the moment if you're planning on using :touch and only require a single callback, you need to look at another option.
https://github.com/rails/rails/issues/8759
I am trying to figure out how i can tell what has changed in an array in the after save callback. Here is an example of code i am using:
class User < ActiveRecord::Base
has_many :user_maps, :dependent => :destroy
has_many :subusers, :through => :user_maps, :dependent => :destroy
has_many :inverse_user_maps, :class_name => "UserMap", :foreign_key => "subuser_id"
has_one :parent, :through => :inverse_user_maps, :source => :user
after_save :remove_subusers
def remove_subusers
if self.subuser_ids_were != self.subuser_ids
leftover = self.subuser_ids_were - self.subuser_ids
leftover.each do |subuser|
subuser.destroy
end
end
end
end
class UserMap < ActiveRecord::Base
belongs_to :user
belongs_to :subuser, :class_name => "User"
end
I am removing the subusers with the after_save callback because i could not get the dependent destroy feature to work through user_maps. Does anyone have any ideas on a way to do this?
Thanks!
You can use the Dirty module accessors http://ar.rubyonrails.org/classes/ActiveRecord/Dirty.html as suggested in Determine what attributes were changed in Rails after_save callback?
In your case the handler you have for after_save will have access to subusers_change which is an array of two elements, first being the previous value and second being the new value.
although not strictly the answer to your question, I think you maybe able to get :dependent => :destroy working if you try the following...
class User < ActiveRecord::Base
has_many :user_maps, :dependent => :destroy
has_many :subusers, :through => :user_maps # removing the :dependent => :destroy option
end
class UserMap < ActiveRecord::Base
belongs_to :user
belongs_to :subuser, :class_name => "User", :dependent => :destroy # add it here
end
By moving the :dependent => :destroy option to the belongs_to association in the UserMap model you set up a cascading delete via the UserMap#destroy method. In other words, calling User#destroy will call UserMap#destroy for each UserMap record, which will in turn call sub_user.destroy for its sub_user record.
EDIT
Since the solution above didn't work, my next suggestion would be to add a callback to the user_maps association, however this comes with a warning that I will add after
class User < ActiveRecord::Base
has_many :user_maps, :dependent => :destroy, :before_remove => :remove_associated_subuser
def remove_associated_subuser(user_map)
user_map.subuser.destroy
end
end
WARNINGS
1) Using a before_remove callback will mean that the user_map.destroy function won't be called if there is an error with the callback
2) You will have to destroy your UserMap record using the method on the User class for example...
# this will fire the callback
u = User.first
u.user_maps.destroy(u.user_maps.first)
# this WONT fire the callback
UserMap.first.destroy
All things considered, this would make me nervous. I would first try modifying your code to make the associations a little less coupled to the same tables, so the :dependent => :destroy option can work, and if you can't do that, add a cascade delete constraint on to the database, at least then your associations will always be removed regardless of where / how you destroy it in your rails app.
First I'm using Rails 3.1 from the 3-1-stable branch updated an hour ago.
I'm developing an application where I have 3 essential models User, Company and Job, Here's the relevant part of the models:
class User < ActiveRecord::Base
has_many :companies_users, class_name: "CompaniesUsers"
has_many :companies, :through => :companies_users, :source => :company
end
class Company < ActiveRecord::Base
has_many :companies_users, class_name: "CompaniesUsers"
has_many :employees, :through => :companies_users, :source => :user
has_many :jobs, :dependent => :destroy
end
class Job < ActiveRecord::Base
belongs_to :company, :counter_cache => true
end
class CompaniesUsers < ActiveRecord::Base
belongs_to :company
belongs_to :user
end
The code works just fine, but I have been wondering if it's possible to:
I want to link a job with an employer, so think of this scenario: A user John who's an employee at Example, he posted the job Rails Developer, so I want to access #job.employer and it should get me back the user John, in other words:
#user = User.find_by_name('john')
#job = Job.find(1)
#job.employer == #user #=> true
So I thought of two possible solutions
First solution
class Job
has_one :employer, :through => :employers
end
class User
has_many :jobs, :through => :employers
end
class Employer
belongs_to :job
belongs_to :user
end
Second solution
class Job
has_one :employer, :class_name => "User"
end
class User
belongs_to :job
end
Which route should I go? Is my code right ?
I have another question, how to get rid of the class_name => "CompaniesUsers" option passed to has_many, should the class be Singular or Plural ? Should I rename it to something like Employees ?
P.S: I posted the same question to Ruby on Rails: Talk
Unless I'm missing something, I'd suggest simply doing
class Job
belongs_to :employer, :class_name => "User"
end
class User
has_many :jobs
end
This would give you methods like
user = User.first
user.jobs.create(params)
user.jobs # array
job = user.jobs.first
job.employer == user # true
You'll need an employer_id integer field in your Jobs table for this to work.
Typically you want to name your pass through model:
company_user
Then you don't need this:
class_name: "CompaniesUsers"
Just make sure the name of your database table is:
company_users
What you have works for you, so that's great. I just find when I don't follow convention I
run in to trouble down the road.
How can I delete nested objects in a form? I found out that I need to add :allow_destroy in the parent model at the accepts_nested_attributes_for directive.
Further, I want to restrict the deletion. A nested object only should be deleted, if the parent object is the only one that retains the association.
Example:
class Internship < ActiveRecord::Base
belongs_to :company
accepts_nested_attributes_for :company, allow_destroy => true
end
class Company < ActiveRecord::Base
has_many :internships
end
Explanation: A company can host many internships. Therefore, I do not want to delete the company record as long as there is at least one other internship associated with it.
You could use dependent => :destroy
class Internship < ActiveRecord::Base
belongs_to :company
accepts_nested_attributes_for :company, allow_destroy => true
end
class Company < ActiveRecord::Base
has_many :internships, :dependent => :destroy
end
If you return false in a before_destroy filter, then the destroy action will be blocked. So we can check to see if there are any internships associated to the company, and block it if so. This is done in the company model.
class Company < ActiveRecord::Base
has_many :internships
before_destroy :ensure_no_internships
private
def ensure_no_internships
return false if self.internships.count > 0
end
end