i am running into an issue with updates to nested attributes for referenced documents not being persisted
> u = User.first
=> #<User...
> u.changes
=> {}
> u.profile.changes
=> {}
> u.attributes = {:profile_attributes => {:weight => 8}}
=> {:profile_attributes=>{:weight=>8}}
> u.changes
=> {}
> u.profile.changes
=> {"weight"=>[14.0, 8.0]}
> u.update
=> true
> u.shipping_profile.changes
=> {"weight"=>[14.0, 8.0]}
update/update_attributes/save all do not persist the nested changes.
i have attr_accessible :profile_attributes declared in the user model.
what is needed for nested attributes to persist when the parent document is already persisted?
Have you got the following in your User class?
accepts_nested_attributes_for :profile
If you're missing that line, i'm pretty sure it will ignore all attempts to update nested records via the parent using update_attributes.
turns out its a mongoid issue. i submit a pull request with the failing test here https://github.com/mongoid/mongoid/pull/978 for anyone else having the same issue. im just manually saving/updating nested records until its resolved
Related
I have a situation where an attribute can be created through a JSON API. But once it is created, I want to prevent it from ever being updated.
This constraint causes my first solution, which is using attr_accessible, to be insufficient. Is there a nice way to handle this type of situation in rails, or do I have to perform a manual check in the update method?
You can use attr_readonly, this will allow the value to be set on creation, but ignored on update.
Example:
class User < ActiveRecord::Base
attr_accessible :name
attr_readonly :name
end
> User.create(name: "lorem")
> u = User.first
=> #<User id: 1, name: "lorem">
> u.name = "ipsum"
=> "ipsum"
> u.save
=> true
> User.first.name
=> "lorem"
There is not a nice way to do that as far as I know, you have to write a custom filter
before_update :prevent_attributes_update
def prevent_attribute_updates
%w(attr1, attr2).each do |a|
send("#{attr1}=", send("#{attr1}_was")) unless self.send("#{attr1}_was").blank?
end
end
I've got a model, Entity.
class Entity
include Mongoid::Document
field :x
field :y
field :z, type => Hash, :default => {} # new field
end
I added a new field to it, a hash. When I try to use it, I get an error. My code is:
e = Entity.first
if e.z["a"] # if there is a key of this in it?
e.z["a"] = e.z["a"] + 1
else
e.z["a"] = 1
end
But, this error with an undefined method get for hash. If I try to create an initializer for it, to set the values in an existing document, it errors with the same error. What am I doing wrong?
Initializer looks like:
e = Entity.first
e.write_attribute(:z, {})
Thanks
Sorted it.
It seems the answer is to set in Mongoid 1.9.5 the hash to:
field :hash_field, :type => Hash, :default => Hash.new
and it can access and initialize it. Not quite understanding why, but happy to have the answer !
I currently have the following:
#threads = current_user.threads.includes(:user, :thread_members)
I then take threads and do the following:
#threads.each do |thread|
thread_members = thread.thread_members_active(current_user)
#threadList << {
:id => thread.id,
:uuid => thread.uuid,
:user_id => thread.user.id,
:last_activity_at => thread.last_activity_at,
:user_count => thread_members.length,
:user_photos => thread_members.collect { |thread_member|
{
:id => thread_member.user.id,
:photo => thread_member.user.photo(:thumb),
:name => thread_member.user.full_name
}
},
:caption => thread.caption
}
end
The issue here is that every EACH loop, rails is hitting the DB for the same basic records. Rails sees to be caching as I see CACHE in the log but it's mighty messy. Leaves me wishing I could do some type of includes so there wasn't so many db requests.
Any ideas on how this can be optimized? Something around including all the users in one db hit?
Thanks
If you don't want any DB queries in the loop, you have to define everything that's used there in the named associations that are included, so instead of a thread_members_active method you'd define a thread_members_active association which has the same behavior. Note that the association also needs to use includes on user. Can't give you more right now, but maybe that helps a bit.
Edit: Check out the "Eager loading of associations" part of this doc:
http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html
This one really has me. I have this validation in my user model:
validates :first_class, :presence => true, :inclusion => %w(Fighter Ranger Magician)
Now, I try an example create in my console:
ruby-1.9.2-p180 :053 > new = User.create(:first_class => 'Magician')
=> #<User id: nil, ...
ruby-1.9.2-p180 :054 > new.errors
=> {:first_class=>["can't be blank", "is not included in the list"]}
Why am I getting this validation error? I SERIOUSLY cannot figure that out.
(If i remove the validation, the user gets created, but first_class is nil :O)
maybe try having attr_accessible :first_class in your model file
You have to tell rails which attributes are writeable through mass-assignment. The new method takes a parameters hash, which is considered mass-assignment. The same is true with update_attributes.
To verify, you could just make a new instance and say object.first_class = 'Magician'. If this also fails, then you know attr_accessible is not the problem.
I wrote this retrieval statement to check if an appointment being saved or created dosent conflict with one thats already saved. but its not working, can someone please point me to where I'm going wrong?
#new_appointment = :appointment #which is the params of appointment being sent back from submit.
#appointments = Appointment.all(:conditions => { :date_of_appointment => #new_appointment.date_of_appointment, :trainer_id => #new_appointment.trainer_id}
)
the error is from the :date_of_appointment => #new_appointment.date_of_appointment this will always be false as:
thank you
At face value, there doesn't appear to be anything wrong with your syntax. My guess is that #new_appointment isn't containing the values you're expecting, and thus the database query is returning different values than you expect.
Try dumping out #new_appointment.inspect or check the logfiles to see what SQL the finder is producing, or use
Appointment.send(:construct_finder_sql, :conditions => {
:date_of_appointment => #new_appointment.date_of_appointment,
:trainer_id => #new_appointment.trainer_id
})
to see the SQL that will be generated (construct_finder_sql is a protected ActiveRecord::Base method).
Update based on your edit
#new_appointment = :appointment should be something like #new_appointment = Appointment.new(params[:appointment]). :appointment is just a symbol, it is not automatically related to your params unless you tell it to.