Determine what ids were removed from array in Rails after_save callback? - ruby-on-rails

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.

Related

Rails 4.2 dependent: :destroy problems with CollectionProxy

I've used dependent: :destroy on models before with out any problem, but in rails 4.2 I'm stuck. The past uses were mainly for classic has_many belongs_to models. It almost seems that #<ActiveRecord::Associations::CollectionProxy is causing my problems.
Models
class Subject < ActiveRecord::Base
has_many :properties
has_many :values, :through => :properties
has_many :tags, :through => :properties
class Property < ActiveRecord::Base
belongs_to :subject
belongs_to :tag
belongs_to :value
class Value < ActiveRecord::Base
has_one :property
has_one :subject, :through => :property
has_one :tag, :through => :property
class Tag < ActiveRecord::Base
has_many :properties
has_many :subjects, :through => :properties
My goals were to
Deleting a Subject would delete all associated Properties and Values
Deleting a Property would delete the associated Value, leaving Subject intact
or, Deleting a Value would delete the associated Property, leaving Subject intact
I tried adding dependent destroy on the values line in Subject and the property line in Value. It would delete the properties, but not the values. I tried putting it on the values properties line and value line in Property and got the same results - it would not delete the Values.
I then tried before_destroy filter and ran into the same type of problem or a ActiveRecord::InvalidForeignKey: PG::ForeignKeyViolation: ERROR when I tried the the model associations. I then hacked it and got it to work:
# In Subject model
before_destroy :destroy_values
def destroy_values
# relations does not seem to work got the Values using a new query
#values.destroy_all
pids = values.pluck(:id)
Value.where(id:pids).destroy_all
end
# in Value model
before_destroy :destroy_property
def destroy_property
property.destroy
end
Not sure what is going on, read up as much as I could on dependent and tried delete_all, and every other thing I saw with no joy!
Yes, it is a strange model, just playing around and tried to replicate the "Whatit?" Apple II database in rails for grins.
Sometimes, when your stuck going around circles, you just have to ask a question. When you don't get an answer, you've had time to rethink the problem. I guess I didn't try all the options.
I think the problem is my not understanding default strategy of nullify. According to my goals, you can't have a value without a property and vice versa. Trying to destroy using a through association would raise the pg error. The simple solution that I apparently didn't try was to dependent destroy properties in the Subject model and dependent destroy value in the Property model. The warning in the guide not to use dependent destroy on a belongs_to association may have started my circle trip. I'm still not sure I understand the warning. My guess is that when subject.properties is destroyed, the subject_id is set to null before the property.value destroy call is made, avoiding the pg error. My cleaned up models:
class Subject < ActiveRecord::Base
has_many :properties, dependent: :destroy
has_many :values, :through => :properties
has_many :tags, :through => :properties
class Property < ActiveRecord::Base
belongs_to :subject
belongs_to :tag
belongs_to :value, dependent: :destroy
class Value < ActiveRecord::Base
has_one :property
has_one :subject, :through => :property
has_one :tag, :through => :property

Rails many-to-many :through association: associated object is not updated after destroying the association object

As I am new to Rails, there is may be a trivial solution. But I could not even find this exact issue somewhere. Other posts deal with destroy vs. delete (I tried both with the same result) or just do not mention how the associated object behaves.
My problem: I want to create a many-to-many association via :through. When I delete an association (i.e. the relation object, not the related objects) I expect that this association is removed (updated) in all model instances of the associated objects. But this does not fully happen.
My example:
Meeting < ActiveRecord::Base
has_many :participations
has_many :users, :through => :participations
User < ActiveRecord::Base
has_many :participations
has_many :meetings, :through => :participations
Participation < ActiveRecord::Base
belongs_to :meeting, :foreign_key => :meeting_id
belongs_to :user, :foreign_key => :user_id
When I create a new association, the associated objects are updated accordingly:
u = User.find(...)
m = Meeting.find(...)
m.users<< u
The same when creating the association this way:
m.participations.create(:user_id => u.id) # this requires to make the user_id attribute accessible
When I now look at the associated user model instance, it got updated as expected:
u.meetings >> contains the newly created association to the meeting m
When I destroy (not delete!) this association, the associated object is not updated as I expect it:
m.users.find_by_user_id(u.id).destroy
m.users >> []
u.meetings >> still contains the destroyed association to meeting m
I would have expected that u.meetings is updated and empty ([]). Adding validations didn't help to solve this:
Meeting < ActiveRecord::Base
validates_associated :contacts
or
Participation < ActiveRecord::Base
validates_presence_of :contact, :interview
What am I doing wrong or what am I missing here?
I am using Rails 3.2.8
Thanks to everyone who is willing to help me.
You should be doing :dependent => :destroy.
Meeting < ActiveRecord::Base
has_many :participations, :dependent => :destroy
has_many :users, :through => :participations
User < ActiveRecord::Base
has_many :participations, :dependent => :destroy
has_many :meetings, :through => :participations
Participation < ActiveRecord::Base
belongs_to :meeting, :foreign_key => :meeting_id
belongs_to :user, :foreign_key => :user_id
This will make sure to destroy the participation if either of the associated user or meeting is destroyed.
You should update your model with the following relationship option:
dependent: destroy
Which will call destroy on the associated objects.
Reference: http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#label-Deleting+from+associations
I guess the problem could be like this. In your example,
m.users.find_by_user_id(u.id).destroy
m.users >> []
u.meetings >> still contains the destroyed association to meeting m
u and u.meetings were already loaded before m.users.find_by_user_id(u.id).destroy. Then u.meetings output the cached data.
You can try u.meetings(true) or u.reload; u.meetings to see if there are any difference.

Rails: Multiple "has_many through" for the two same models?

Can't wrap my head around this...
class User < ActiveRecord::Base
has_many :fantasies, :through => :fantasizings
has_many :fantasizings, :dependent => :destroy
end
class Fantasy < ActiveRecord::Base
has_many :users, :through => :fantasizings
has_many :fantasizings, :dependent => :destroy
end
class Fantasizing < ActiveRecord::Base
belongs_to :user
belongs_to :fantasy
end
... which works fine for my primary relationship, in that a User can have many Fantasies, and that a Fantasy can belong to many Users.
However, I need to add another relationship for liking (as in, a User "likes" a Fantasy rather than "has" it... think of Facebook and how you can "like" a wall-post, even though it doesn't "belong" to you... in fact, the Facebook example is almost exactly what I'm aiming for).
I gathered that I should make another association, but I'm kinda confused as to how I might use it, or if this is even the right approach. I started by adding the following:
class Fantasy < ActiveRecord::Base
...
has_many :users, :through => :approvals
has_many :approvals, :dependent => :destroy
end
class User < ActiveRecord::Base
...
has_many :fantasies, :through => :approvals
has_many :approvals, :dependent => :destroy
end
class Approval < ActiveRecord::Base
belongs_to :user
belongs_to :fantasy
end
... but how do I create the association through Approval rather than through Fantasizing?
If someone could set me straight on this, I'd be much obliged!
Keep your first set of code, then in your User Model add:
has_many :approved_fantasies, :through => :fantasizings, :source => :fantasy, :conditions => "fantasizings.is_approved = 1"
In your Fantasizing table, add an is_approved boolean field.

Validating associated objects before object.save, or rolling back object.save on associated object vaidation failure

Right down to business....
There are tasks, which have assigned users
class Task < ActiveRecord::Base
has_many :task_assignments, :dependent => :destroy
has_many :assigned_users, :through => :task_assignments, :source => :user
validates_associated :task_assignments
end
And users have assigned tasks
class User < ActiveRecord::Base
has_many :task_assignments, :dependent => :destroy
has_many :assigned_tasks, :through => :task_assignments, :source => :task
end
The task_assignments table looks like this
class TaskAssignment < ActiveRecord::Base
validates_presence_of :user, :message => 'You must add some USERS fool!'
belongs_to :user
belongs_to :task
end
Those associations seem to be working well :0)
Here's the rub - when I add a new task through /tasks/new, I also want to specify a list of users assigned to that task, which the form is returning in "params[:users_list][:id]".
I can get this to work, but I don't want the form to validate unless there is at least one user selected.
I can't for the life of me figure out how to get this validation to take place in the models rather than in the create method.
As you can see, I've thrown "validates _associated :task _assignments" in the tasks method, but to no avail. I'm clearly in over my head.
Thanks for your help.
I think you have to name the parameter user_ids...
f.e.:
params[:users_ids][:id]

Rails : uninitialized constant error on Active Record destroy

I am having an issue when trying to destroy an active record instance.
It involves the following AR
class Client < ActiveRecord::Base
has_many :phone_numbers, :dependent => :destroy
has_many :email_addresses, :dependent => :destroy
has_many :user_clients , :dependent => :destroy
has_many :users, :through => :user_clients
end
class UserClient < ActiveRecord::Base
belongs_to :user
belongs_to :client , :dependent => :destroy
has_many :instructions, :dependent => :destroy
end
When performing a destroy on a Client instance I am given the following error
#dead_man = Client.find(params[:id])
#dead_man.destroy => uninitialized constant UserClient::Instruction
I am really not sure where this error is coming from. Any help is greatly appreciated!
It's not finding your Instruction model. Make sure it's in the models directory, appropriately named, extends ActiveRecord::Base, etc.
Also, you should remove the :dependent => :destroy from the belongs_to :client line in the UserClient model, unless you really want deletion of a user_client to result in deletion of the client. It sounds like it should be the other way around, and that's already set up in the Client model.
Also check that the file name corresponds with the class name. In my case I had
Class NameSpace::MyStats
in
namespace/old_stats.rb
and Rails kept on throwing the "uninitialized constant error" until I changed it to
namespace/my_stats.rb

Resources