I have a model in ruby on rails with the below code, which uses a singelton class definition. Also, som metaprogramming logic. But, I don't understand when this code will invoke.Is it when an attribute below specified is editing?
class Product < ApplicationRecord
class << self
['cat_no', 'effort', 'impact', 'effect', 'feedback'].each do |attr|
define_method "update_#{attr}" do |pr, count, user_id|
pr.order=pr.cat_no
pr.idea=pr.description
pr.update("#{attr}"=>count,:last_modified_by=>user_id)
end
end
end
end
Please help.
Thanks
This code generates five methods, one for each attribute name in the list. All these generated methods take three arguments and will basically look like this (I use the impact attribute name as an example):
def self.update_impact(pr, count, user_id)
pr.order = pr.cat_no
pr.idea = pr.description
pr.update("impact" => count, :last_modified_by => user_id)
end
That means there are five methods generated that update the passed in pr with some data from itself and with a count and a user_id.
Note that this method only deals with a specific pr therefore it is certainly better to use an instance instead of a class method as Stefan already suggested in his comment. And IMO there is not really a benefit in meta-programming here. I would change the logic to
def update_count(type, count, user_id) # or any another name that makes sense in the domain
if type.in?(%i[cat_no effort impact effect feedback])
update(
:order => cat_no,
:idea => description,
:last_modified_by => user_id,
type => count
)
else
raise ArgumentError, "unsupported type '#type'"
end
end
and call it instead of
Model.update_impact(pr, count, user_id)
like this
pr.update_count(:impact, count, user_id)
Related
Okay, this is kind of a followup to this question: Is overriding an ActiveRecord relation's count() method okay? Basically I have a relation I want to paginate on, and counting it is slow, so I'm overriding count() with a cached counter attribute.
I have:
class CountDelegator < SimpleDelegator
def initialize(obj, total_count)
super(obj)
#total_count = total_count
end
def count
#total_count
end
end
class Parent
has_many :kids do
def chatty_with_singleton
resultset = where(:chatty => true)
def resultset.count
proxy_association.owner.chatty_kids_count
end
resultset
end
def chatty_with_delegation
resultset = where(:chatty => true)
CountDelegator.new(resultset, proxy_association.owner.chatty_kids_count)
end
end
end
p = Parent.first
Now, when I do either p.kids.chatty_with_singleton.count or p.kids.chatty_with_delegation.count, I use the cached count. Great! However, the following behave differently:
# Uses the cached count
p.kids.chatty_with_singleton(:order => "id desc").count
# Does not use the cached count
p.kids.chatty_with_delegation(:order => "id desc").count
I'm totally confused — I don't know why these two cases would behave differently in practice. (Yes, I'm aware that p.kids.chatty_with_singleton(:id => 0).count returns the wrong value and I am okay with that.)
Why does defining the method on the singleton resultset cause that definition to dominate, while the delegator doesn't?
You're re-implementing the built-in counter_cache option provided by belongs_to. You simply specify the column of your cache as well, if you're not using the rails default column.
Using the counter_cache will automatically read the cached value on table instead of executing a COUNT.
In my model subject.rb i have the following defined
has_many :tutors, through: :profiles
def self.search(param)
where("name like ?", "%#{param}%")
end
So something like Subject.search("English") works perfectly fine in rails console.
What i would like to know is that if i do subject = Subject.first and i can do stuff like subject.id and it returns the subject ID to me.
Whereas when i do subject = Subject.search("English") i am unable to do something like subject.id
Because i'm trying to link the search function to my tutor.rb model with the following code.
def self.subject_search(s)
#tutor = Tutor.all
#tutor.each do |x|
y = x.subjects.search(s)
unless y.empty?
return x
end
end
end
Which works but only returns one Tutor and not all Tutors that have the subject.
I also tried this instead
def self.subject_search(s)
#subject = Subject.search(s)
if #subject
#subject.tutors
end
end
But thats when i realised #subject.tutors doesn't work, as explained above, if i do subject = Subject.search("English") i can't manipulate subject with any methods.
What am i doing wrongly?
Using a #where returns an array of objects meeting the criteria.
Subject.search('Math') => ['Math1', 'Math2', 'Math3'] # Objects of course
In your case, you should be doing Subject.find_by_name('English') which returns the first object satisfying your query. Then you can call #tutors on your Subject model assuming you have the method defined.
If you do have to use the like operator no matter what (which I do not recommend), here's what will happen.
s = Subject.search('En') # => ['English', 'Environmental Science', ..]
s.tutors # => Undefined method tutors for Array class
Here, s is an array of Subject models rather than a singular Subject which is the reason why its not working. You either need something to narrow it down more or loop through it which is probably not what you want anyway.
This is the weirdest thing ever happened to me with ruby/rails.
I have a model, Store, which has_many Balances. And I have a method that gives me the default balance based on the store's currency.
Store model.
class Store < ActiveRecord::Base
has_many :balances, as: :balanceable, dependent: :destroy
def default_balance
#puts self.inspect <- weird part.
balances.where(currency: self.currency)[0]
end
...
end
Balance model.
class Balance < ActiveRecord::Base
belongs_to :balanceable, :polymorphic => true
...
end
Ok, so then in the Balance controller I have the show action, that will give me a specific balance or the default one.
Balance controller.
class Api::Stores::BalancesController < Api::Stores::BaseController
before_filter :load_store
# Returns a specific alert
# +URL+:: GET /api/stores/:store_id/balances/:id
def show
#puts #store.inspect <- weird part.
#balance = (params[:id] == "default") ? #store.default_balance : Balance.find(params[:id])
respond_with #balance, :api_template => :default
end
...
private
# Provides a shortcut to access the current store
def load_store
#store = Store.find(params[:store_id])
authorize! :manage, #store
end
end
Now here is where the weird part comes...
If I make a call to the show action; for example:
GET /api/stores/148/balances/default
It returns null (because the currency was set as null, and there is no Balance with null currency), and the SQL query generated is:
SELECT `balances`.* FROM `balances` WHERE `balances`.`balanceable_id` = 148 AND `balances`.`balanceable_type` = 'Store' AND `balances`.`currency` IS NULL
So I DON'T know why... it is setting the currency as NULL. BUT if in any where in that process I put
puts #store.inspect
or inside the default_balance method:
puts self.inspect
it magically works!!!.
So I don't know why is that happening?... It seems like the store object is not getting loaded until I "inspect" it or something like that.
Thanks
Sam and Adrien are on the right path.
ActiveRecord overrides method_missing to add a whole bunch of dynamic methods including the accessors for the column-backed attributes like Store#currency. While I'm glossing over a lot, suffice it to say that when the logic is invoked then the dynamic class/instance methods are added to the Store class/instances so that subsequent calls no longer require the method_missing hook.
When YOU overrode method_missing without calling super, you effectively disabled this functionality. Fortunately, this functionality can be invoked by other means, one of which you tripped upon when you called store#inspect.
By adding the call to super, you simply assured that ActiveRecord's dynamic methods are always added to the class when they're needed.
OK finally after a lot of debugging, I found the reason...
In the Store model I have a method_missing method and I had it like this:
def method_missing method_name, *args
if method_name =~ /^(\w+)_togo$/
send($1, *args).where(togo: true)
elsif method_name =~ /^(\w+)_tostay$/
send($1, *args).where(tostay: true)
end
end
So when I was calling self.currency it went first to the method_missing and then returned null. What I was missing here was the super call.
def method_missing method_name, *args
if method_name =~ /^(\w+)_togo$/
send($1, *args).where(togo: true)
elsif method_name =~ /^(\w+)_tostay$/
send($1, *args).where(tostay: true)
else
super
end
end
But I continue wondering why after I had called puts #store.inspect or puts self.inspect it worked well?. I mean, why in that case that super call wasn't needed?
I created this helper method. In my view I call it with days_left(duedate). I dont really like my helper. Is it possible to use it with self. Since I dont really know how self is being used. Is it the same as this in java or javascript? What object is it related to? Feel free to tune this method. Thx for your time!
def days_left(duedate)
(if duedate.date == Date.today
"Today"
elsif duedate.date-Date.today < 1
"expired"
elsif duedate.date-Date.today == 1
"Tomorrow"
else
"#{(duedate.date-Date.today).to_i}"
end).to_s.html_safe
end
You might try moving this method to your model.
This would be similar to adding a 'full_name' method to a model with the attributes 'first_name' and 'last_name.' You wouldn't store 'full_name' separately in your database, because that would result in redundant, denormalized data.
For example:
class Employee < ActiveRecord::Base
def full_name
"#{first_name} #{last_name}"
end
end
So you could similarly add the 'days_left' method to your model, which fits there because it's adding a friendlier version of an existing data attribute.
I have a model that looks something like this:
class Comment < ActiveRecord::Base
...
#allow editing comment if it is moderated and the user passed-in
#is the one that owns the comment
def can_edit?(user)
moderated? and user.Type == User and user.id == self.user_id
end
...
end
And a call in a view:
<%= link_to 'Show Comment', #comment if #comment.can_show?(current_user) %>
I need to write many such methods in many different models - sort of validation checks to see if current_user is allowed to
do something on a model.
But it feels cumbersome - especially the need to check that the passed-in user is indeed a object of type User.
What's a clean, best-practice way to do this sort of thing? Am I on the right track? (i.e. should I be adding such methods to a model or somewhere else)
Note
I am using scoped queries to get the comments and other models, but in some cases I cannot scope the query so I have to use the can_xxxx? methods
Ps. Is what I'm doing considered a "fat model"?
Create a module containing all the authorization methods and include the module to all the classes requiring authorization.
Add a file called authorization.rb to app/models directory.
module Authorization
def can_edit?(user)
moderated? and user.is_a?(User) and user.id == self.user_id
end
def self.included(base)
base.send(:extend, ClassMethods)
end
module ClassMethods
# add your class methods here.
end
end
Add a file called authorization.rb to config/initializers directory.
%w(
Comment
Post
).each do |klass|
klass.constantize.include(Authorization)
end
Now Comment and Post models will have all the authorization methods.
Other approach is to use your current named_scope.
class Post
named_scope :accessible, lambda { |user|
{
:conditions => { :user_id => user.id, :moderated => true}
}
}
end
Post controller actions
class PostsController
def index
#posts = Post.acessible(current_user)
# process data
end
def show
# throws record not found when the record is not accessible.
#post = Post.acessible(current_user).find(params[:id])
# process data
end
end
I like this approach as it uses the same logic for accessing an array of objects or a single object.
You can add the named_scope to the module to avoid repeated definitions:
module Authorization
def self.included(base)
base.named_scope :accessible, lambda { |user|
{
:conditions => { :user_id => user.id, :moderated => true}
}
}
end
module ClassMethods
# add your class methods here.
end
end
Make sure to include the module in required classes as suggested earlier.
I don't think what you're doing is necessarily wrong. I see three ways to simplify, though:
1) track self.user as well as self.user_id. Then you can say:
def can_show?(user)
moderated ? and user == self.user
end
Note, this might add overhead either with DB lookup times and/or memory footprint.
2) Use #is_a? in order to check ancestry and not just class equality:
def can_show?(user)
moderated ? and user.is_a?( User ) and user.id == self.user_id
end
3) If passing in a non-user is wrong, you might want to raise an error when this happens:
def can_show?(user)
raise "expected User, not #{ user.class.to_s }" unless user.is_a?(User)
moderated ? and user.id == self.user_id
end
As for Q2, I haven't heard the terminology "fat model." Is it referenced anywhere in particular?
Re: fat model and skinny controller
This is the idea of pushing logic into the model rather than having it in the controller (or worse, the view).
A big benefit is to help with testing; also the focus of placing more logic in the model rather than in the controller. Remember that it is not uncommon to have controllers work with multiple models.
Putting the logic into a model rather than a controller often means that the business rules are being baked into the model--which is exactly where they belong.
A possible downside is that any information available to the controller that is not available in the model needs to be explicitly passed into the model's methods or "set" using a model's instance variables.
Your example of needing to pass the current user into the model illustrates the issue.
Overall though, I and many others have found that fat models tend to work out better than not.