I am using Rails and mongoid to work with mongodb.
Usually in rails when working with Active:Record, you have access to the method .toggle! which simply allows you to invert the value of a boolean field in your db.
Unfortunately this method is not available for mongoDB:
user = User.first
user.toggle!(:admin)
NoMethodError: undefined method `toggle!' for #<User:0x00000100eee700>
This is unfortunate... and stupidly enough I don't see how to get around without some complicated code...
Any suggestion on how to achieve the same result concisely ?
Thanks,
Alex
ps: also one of the problems is that when I want to modify the field, it goes through validation again... and it's asking for the :password which I don't save in the db, so:
User.first.admin = !User.first.admin
won't even work :(
The issue here is specifically mongoid, not mongodb. toggle! is a part of ActiveRecord::Base, but fortunately it's not hard to replicate.
def toggle!(field)
send "#{field}=", !self.send("#{field}?")
save :validation => false
end
Add that into your model (or add it into a module, and include it in your model), and your Mongoid models will gain functionality equivalent to what you're used to in AR. It will read the field's value, invert it, write it (through the setter, per the toggle! documentation), and then save the document, bypassing validation.
# Get object's boolean field and toggle it
# #param [Object] mongoid object
# #param [String, Symbol] flag
# #example
# foo = User.find('123')
# toggle_flag!(object: foo, flag: :bar)
def toggle_flag!(object:, flag:)
object.update(flag => !object[flag])
object.save!
end
Ok the validation did not work because of a type, the code should be:
save :validate => false (not :validation)
Related
I am trying to send a notification email in my rails app only if the value of my column status was modified by the current update. I tried using Active Model Dirty as was suggested in some post and the status_changed? method. Unfortunately my email is never sent because #partnership.status_changed? constantly returns false even though the value of status was indeed changed during the last update. Here's my controller code :
def update
authorize #partnership
if #partnership.update(partnership_params)
send_notification_email
render json: {success: "partnership successfully updated"}, status: 200
else
render_error(nil, #partnership)
end
end
private
def send_notification_email
PartnershipMailer.partnership_status_change(#partnership).deliver_now if #partnership.status_changed?
end
I have also included Active Model Dirty in my model :
class Partnership < ActiveRecord::Base
include ActiveModel::Dirty
What am I doing wrong ?
.update also saves the model after updating it's data, therefore resetting the dirty-values. Try using .assign_attributes. It will just assign the attributes, then you can check for changes, and finally remember to save the model.
As #Thounder pointed out, the ActiveModel::Dirty method <attribute>_changed? is reset whenever you save a record. Thus, it only tracks changes between saves.
For your use case, what you want to use is the previous_changes method, which returns a hash with the key being the attribute changed and the value being an array of 2 values: old and new.
person = Person.new(name: "Bob")
person.name_changed? # => true
person.save
person.name_changed? # => false (reset when save called)
person.previous_changes # => { name: [nil, "Bob"] }
person.previous_changes[:name] # => returns a "truthy" statement if :name attribute changed
My pseudo-code may be wrong, but the principle works. I've been bitten by this "gotcha" before, and I wish the Rails core team would change it.
I understand their reasoning, but it makes more sense to me to track <attribute>_changed? after a save as well, because that seems the common use case to me.
You can try this method to check the changed attributes for the active record.
#partnership.changed.include?("status")
If it returns true then we have status attribute which was changed in this record.
Use #partnership.saved_change_to_status? or #partnership.saved_change_to_attribute(:status) as per docs.
Here is a one line method you can into the model which is the best for your case :
after_commit :send_notification_email, if: Proc.new { |model| model.previous_changes[:status]}
I'm reading Rails Devise gem documentation and it says:
If the page could potentially not have a current_user set then:
if current_user.try(:admin?) # do something end
I have tried it without question mark
current_user.try(:admin)
and it works the same way returning true or false.
Do I miss something? Is there any difference and how can I see it?
Ruby is somewhat unusual in that it lets you include a wide range of characters in the names of methods including ? and !.
They have no special significance to the interpreter but the language convention is that:
methods ending with ? are interrogative - they should ALWAYS return true or false.
methods ending with ! either mutate the object the are called on or may raise a exception.
So why does it matter at all? In this particular case it does not matter since your user class has an accessor for the #admin instance variable created by ActiveRecord - just like any other column.
If it did not however current_user.try(:admin) would always return nil. Remember that instance variables are always private in Ruby until you provide an accessor*.
# Just a plain old Ruby class - not an ActiveRecord model
class User
def initialize
#admin = true
end
def admin?
#admin
end
end
User.new.try(:admin) # is always nil...
This is because User does not respond to :admin and .try prevents a NoMethodError and just returns nil instead.
ActiveRecord and accessors:
In a plain old ruby class you would add accessors to make the instance variable #admin available:
class User
def initialize
#admin = true
end
attr_accessor :admin
end
Which does this:
class User
def initialize
#admin = true
end
# getter
def admin
#admin
end
# setter
def admin=(val)
#admin = val
end
end
ActiveRecord reads the schema from your database and uses metaprograming to auto-magically add accessors to your model classes. They are a bit more complex than the example above but its the same basic principle. Thats why your User model responds to #admin.
By default, rails ActiveRecord object attributes that are boolean can either be called with or without a question mark (?).
By convention, it is easier to read if you add the ?, and that also shows that it is boolean at first glance.
So, reading this gives the impression that you are asking a question in English.
Therefore, my guess is that admin is a boolean field on the user.
Also, Tom above is very correct.
There is probably no functional difference, in this case.
I'm guessing admin is a boolean field in the users database table. So, user.admin will return either true or false -- no surprises here!
For each column in the table, Rails will also automatically generate an associated method prepended with an ?. For example, if you have a column foo, then there will be a method foo? - which will return true or false depending on the value of foo.
For example, if current_user.name == "Tom" then current_user.name? == true. And if current_user.name == nil, then current_user.name? == false.
It's very rarely necessary to use the ? methods in your code, since all objects are either "truthy" or "falsey" in ruby anyway. But it can sometimes be useful to show intent, and makes the code easier to read, as it's clear that the value is only being used in a boolean manner.
I recently 'discovered' the update_attribute method. So, I started changing sequences like
self.attribute = "foo"; save
in model or controller methods by
self.update_attribute(:attribute, "foo")
Now, the more I'm doing this, the more I'm wondering whether this is "good practice", and whether this method was intended to be used this way.
Any input from the "pro's" on this?
I would suggest using update_attribute for flags or any update operation that does not need validations since it does not fire validations. From rails documentation we can read:
Updates a single attribute and saves the record without going through
the normal validation procedure. This is especially useful for boolean
flags on existing records. The regular update_attribute method in Base
is replaced with this when the validations module is mixed in, which
it is by default.
Whereas update_attributes does:
Updates all the attributes from the passed-in Hash and saves the
record. If the object is invalid, the saving will fail and false will
be returned.
Let's look at the code now:
def update_attribute(name, value)
send(name.to_s + '=', value)
save(false)
end
def update_attributes(attributes)
self.attributes = attributes
save
end
It's always better to use update_attribute, or update_attributes if you need to update a single instance with simple data, as you can read "UPDATE" and know that you are "UPDATING".
You must know also that there is a method called update_column, that does 'kinda' the same stuff, but, update_column does NOT update the updated_at timestamp on the database.
Also, if you need to edit a large amount of instances/rows in the database with the same value, you have a method called update_all. Here is an example
#instances = Instance.all
#instances.update_all(:attribute, value)
and that will update all the attributes of that table. You will find this usefull after doing werid migrations.
Besides all of this, you can always use the 'save' way, I strongly recomend this when you have to calculate a lot of data to update a single instance. Here is an example:
#BAD
def updater_method
foo = Bar.first
foo.update_attributes(attr_one: some_calcule_method, attr_two: some_other_calcule_method, attr_three: some_more_calcule_method)
end
#GOOD
def saver_method
foo = Bar.first
foo.attr_one = some_calcule_method
foo.attr_two = some_other_calcule_method
foo.attr_three = some_more_calcule_method
etc
foo.save!
end
This will help you in debbuging, so if any method fails, you can see it clearly, with the line number and all that stuff.
Regards, Lucas.
This is going to sound pretty crazy, but I'm trying to build a generic decoration-based system which will allow a decorated class to do all kinds of crazy stuff with attributes. The goal is to be able to define attributes at a high level, decorate an ORM class (ActiveRecord, for example, though our primary case is actually quite a bit different), and use those decorations in various places in the app to automate some dynamic "magic' our app needs. For instance, we'll use the attributes to automatically generate forms and views, translate complex form hashes into flatter structures, etc.
To accommodate both use cases we've identified so far, I have a mixable module and a decorator (using Draper so Rails form magic still works, though I'm not married to Draper necessarily) which look more or less like this (obviously lots of details are omitted):
class DecoratorThing < Draper::Decorator
include CoreMixinStuff
delegate_all
end
module CoreMixinStuff
extend ActiveSupport::Concern
module ClassMethods
def attribute(stuff, blah)
attribute = AttributeDefinition.new(...)
add_translation_methods(attribute)
...
end
def add_translation_methods(attribute)
name = attribute.name
reader = name
writer = "#{name}="
# In the case of field wrappers, we have to alias the original reader and writer so we
# don't overwrite them completely
if attribute.translation_type == :wrapper
alias_method :"_orig_#{reader}", reader
alias_method :"_orig_#{writer}", writer
# Otherwise, we need to error if the reader or writer would collide
elsif instance_methods.include?(reader) || instance_methods.include?(writer)
raise RuntimeError.new("Cannot define an attribute which overrides existing methods (#{name.inspect})")
end
end
end
end
Then the actual decorator for a specific instance does things like this:
class FooDecorator < DecoratorThing
decorates Foo
attribute :field, multiple: true, serialize: true
attribute :field2, field: :delegation_field
attribute :field3 do |field|
field.subtype ...
field.subtype ...
end
end
The intent there would be to allow Foo#field to take an array and serialize it internally into a string before sending it off to wherever the decorated object takes it. Foo#field2 would just pass data as-is to delegation_field. Foo#field3 would take a complex hash of data and delegate it to the subtype fields.
The latter two cases are painful, but I have them working in a prototype. The first is the problem because of the alias_method stuff above - since the attribute method is run on the decorator, the method I'm trying to alias doesn't actually exist yet. It's not until FooDecorator.new(some_foo_instance) is called that those other instance methods are available.
I think my options are limited to the following, but I'm hoping there's some better choice:
Give up on decoration and just accept that this whole thing has to be a mixin instead
Give up on the mixin, requiring decoration instead, and go through the decorated object rather than aliasing the methods
Give up on field wrappers and require attributes to always have a unique name and delegate to a field (in the example above, attribute :field... would become attribute :field_wrapper, multiple: true, serialize: true, field: "field")
Give up on serializing data, making it the user's responsibility to properly define / override methods to handle the data they define
The fourth option is probably the sanest, but I've made a lot of assumptions around being able to serialize, so if somebody else knows a nice way to make this happen, that'd be super swell.
I think I have an answer that fits this question.
Basically, my solution adds a proxy column over the top of an existing column associated with an active-record model.
This proxy column overrides the original column's accessor methods. The basic proxy functionality doesn't do much beside set and get the value of original columns.
The actual code is quite long so I've created a gist for it. Check it out here.
The proxy column object can be subclassed/overridden to provide any sort of functionality required. For example, in your code AttributeDefinition would subclass ProxyColumn. The AttributeDefinition would act as a proxy between the different attributes and the values. It could wrap/unwrap the attributes value in a DecoratorThing based on whatever conditions that you deem appropriate.
One thing it doesn't do, at this stage, is provide a way of overriding how/what methods are added. However, all that could easily be changed based on your needs. I actually based that part off your add_translation_methods method anyways.
This is the basic usage to define the columns:
class MyModel
# Add the concern to get the functionality
include DataCollectionElements # concern
# create proxy column and set various options
proxy_column :my_col_1
proxy_column :my_col_2, :alias => [:col1, col2, col3]
proxy_column :my_col_3, :column => :actual_col_name
# define the proxy object using class/string/symbol
proxy_column :my_col_4, :proxy => MyProxy # or 'MyProxy' or :my_proxy
# define the proxy object using a proc/lambda
proxy_column :my_col_5, :proxy => ->(model, code, options) { MyProxy.new(model, code, options) }
proxy_column :my_col_6, :proxy => proc {|model, code, options| MyProxy.new(model, code, options) }
# define the proxy object using a block
proxy_column :my_col_7 do |model, code, options|
MyProxy.new(model, code, options)
end
end
Background
I'm using ledermann-rails-settings (https://github.com/ledermann/rails-settings) on a Rails 2/3 project to extend virtually the model with certain attributes that don't necessarily need to be placed into the DB in a wide table and it's working out swimmingly for our needs.
An additional reason I chose this Gem is because of the post How to create a form for the rails-settings plugin which ties ledermann-rails-settings more closely to the model for the purpose of clean form_for usage for administrator GUI support. It's a perfect solution for addressing form_for support although...
Something that I'm running into now though is properly validating the dynamic getters/setters before being passed to the ledermann-rails-settings module. At the moment they are saved immediately, regardless if the model validation has actually fired - I can see through script/console that validation errors are being raised.
Example
For instance I would like to validate that the attribute :foo is within the range of 0..100 for decimal usage (or even a regex). I've found that with the previous post that I can use standard Rails validators (surprise, surprise) but I want to halt on actually saving any values until those are addressed - ensure that the user of the GUI has given 61.43 as a numerical value.
The following code has been borrowed from the quoted post.
class User < ActiveRecord::Base
has_settings
validates_inclusion_of :foo, :in => 0..100
def self.settings_attr_accessor(*args)
>>SOME SORT OF UNLESS MODEL.VALID? CHECK HERE
args.each do |method_name|
eval "
def #{method_name}
self.settings.send(:#{method_name})
end
def #{method_name}=(value)
self.settings.send(:#{method_name}=, value)
end
"
end
>>END UNLESS
end
settings_attr_accessor :foo
end
Anyone have any thoughts here on pulling the state of the model at this point outside of having to put this into a before filter? The goal here is to be able to use the standard validations and avoid rolling custom validation checks for each new settings_attr_accessor that is added. Thanks!
Here is a newer version that works in the new 2x syntax. Yes it is ugly and does double eval.
This produces namespaces method names and adds them to the attr_accessible list. The names are in the form of "#{namespace}_#{attribute} and can be use in forms. I am monkeying with a ppatch to the gem to do this automatically but I an not there yet.
has_settings do |s|
eval 'def self.settings_accessors(namespace, defaults)
defaults.keys.each do |method_name|
attr_accessible "#{namespace}_#{method_name}"
eval "def #{namespace}_#{method_name}
self.settings(:#{namespace.to_s}).send(:#{method_name})
end
def #{namespace}_#{method_name}=(value)
self.settings(:#{namespace}).send(:#{method_name}=, value)
end
"
end
end'
namespace = :fileshare
defaults = {:media => false, :sit => false, :quota_size => 1}
s.key namespace, :defaults => defaults
self.settings_accessors(namespace, defaults)
end