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
Related
I have the following Model
class Will < ApplicationRecord
belongs_to :user
belongs_to :product
has_one :willFamilyDetail, :dependent => :destroy
has_one :childCompensate, :dependent => :destroy
has_one :wifeCompensate, :dependent => :destroy
has_one :willDebt, :dependent => :destroy
has_one :willLegalHeirBequest, :dependent => :destroy
has_one :willGrandchildrenBequest, :dependent => :destroy
has_one :willBequestOther, :dependent => :destroy
end
and all other models have belongs_to.
When I use Rails console to delete the Will object, other objects still appear in the database, they must get destroyed right?
What am I doing wrong?
ActiveRecord association symbols must be snake case, not camel case, following Ruby convention. Converting each association name from camel case to snake case (:willFamilyDetail to :will_family_detail, etc.) solves the issue.
I'm trying to set up a has_many :through association between three models: Trip, Location and LocationsTrip, but the associations just don't seem to be picking each other up.
I set up my associations:
class Trip < ActiveRecord::Base
belongs_to :user
has_many :locations_trips
has_many :locations, :through => :locations_trips
accepts_nested_attributes_for :locations_trips, :allow_destroy => :true
accepts_nested_attributes_for :locations, :allow_destroy => :true
end
class Location < ActiveRecord::Base
has_many :locations_trips, :dependent => :destroy
has_many :trips, :through => :locations_trips
end
class LocationsTrip < ActiveRecord::Base
belongs_to :locations
belongs_to :trips
end
When I run Trip.last.locations in the Rails console I get
NameError: uninitialized constant Trip::Locations
so I've obviously missed something crucial, but I feel as if I've been through every similar answer on here and can't see where I'm going wrong.
It's probably worth mentioning I'm trying to set this up with Trips accepting nested attributes for Locations so in the Trip form partial I've got a f.fields_for :locations do |builder| etc, but when I load up the page I get the same NameError as before.
If anyone can point me in the right direction I'd be massively grateful - I feel like I'm getting tunnel vision on this.
I'm using Ruby 2.1.2 and Rails 4.2.0.
It looks like you're using plural names for the join table belongs_to associations. Try changing to:
class LocationsTrip < ActiveRecord::Base
belongs_to :location
belongs_to :trip
end
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
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.
I've tried persistently googling this error, but to no avail. I currently have these models
app/models/survey.rb
class Survey < ActiveRecord::Base
belongs_to :user
has_attached_file :original, :default_url => "/public/:class/:attachment/:basename.:extension"
has_many :sub_surveys, :dependent => :destroy
end
app/models/sub_survey.rb
class SubSurvey < ActiveRecord::Base
belongs_to :survey
has_many :questions, :dependent => :destroy
end
app/models/question.rb
class Question < ActiveRecord::Base
belongs_to :sub_survey
validates_presence_of :sub_survey
acts_as_list :scope => :sub_survey
#after_destroy :destroy_orphaned_choices
has_many :answers, :dependent => :destroy
has_many :choices, :dependent => :destroy
end
app/models/choice.rb
class Choices < ActiveRecord::Base
belongs_to :question
validates_presence_of :question
end
app/models/answer.rb
class Answer < ActiveRecord::Base
belongs_to :question
belongs_to :user
belongs_to :game
validates_uniqueness_of :question_id, :scope => [:user_id, :game_id]
end
Now when I try to destroy a survey, I get an error
uninitialized constant Question::Choice
That traces through /vendor/rails/active* stuff after the survey.destroy
Then when I try to access choices from question.Choices, I get an error
undefined method `Choices' for #<Question:0xb7224f2c>
which for some reason has this on top of the trace-stack
vendor/rails/activerecord/lib/active_record/attribute_methods.rb:256:in `method_missing'
vendor/plugins/attribute_fu/lib/attribute_fu/associations.rb:28:in `method_missing'
app/views/answers/_answer.html.erb:7:in `_run_erb_47app47views47answers47_answer46html46erb'
I do use attribute_fu when importing surveys in xml-format, but I have no idea why the trace of question.Choices has it.
I also tried renaming choices to choicealternatives, but that didn't have an effect.
Any ideas?
Your Choices table has already got a pluralised name which may be causing problems. Ideally that table should be called Choice otherwise your has_many :choices should specify the class_name option too. E.g.
has_many :choices, :class_name => 'Choices'
Though I'd opt for renaming the class and table Choice if you can.
Attachment_fu is probably appearing in the stack trace because they have overridden or aliased the method_missing method to add their own behaviour. It's not necessarily anything to be concerned about.
I'm not sure why you get the error when destroying a Survey, but you're getting this
undefined method `Choices' for #<Question:0xb7224f2c>
because you should be accessing it like this:
question.choices # No capitalization
I think that should solve one of the problems.