Hi everyone,
I have a working named_scope here, however it''s too cluttered.
Anyone got a better (more efficient) and concise alternative?
Thanks.
===========================================named_scope :filter, lambda { |*args|
if
args.first && args.second == nil
{} # return all records
if args.first.blank?
{ :conditions => ["status = ?", args.second] }
if
args.second.blank?
{ :conditions => ["invoice_number= ?", args.first] }
else
{ :conditions => ["nvoice_number= ? and status = ?",
args.first, args.second] }
end
end
end
}
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jul 16, 11:42 am, Jermaine <jermaine2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi everyone, > > I have a working named_scope here, however it''s too cluttered. > Anyone got a better (more efficient) and concise alternative? > > Thanks. >well named_scope :filter, lambda {|*args| {:conditions => {:status => args.first, :invoice_number => args.second}.reject{|k,v| v.blank?}} } is more compact and i think does the same thing as your code. With anything like this any time you save when building up the conditions will be dwarfed by the time it takes to run the actual query Fred> ===========================================> named_scope :filter, lambda { |*args| > if > args.first && args.second == nil > {} # return all records > > if args.first.blank? > { :conditions => ["status = ?", args.second] } > > if > args.second.blank? > { :conditions => ["invoice_number= ?", args.first] } > > else > { :conditions => ["nvoice_number= ? and status = ?", > args.first, args.second] } > end > end > end > }-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hi Fred, Thanks for the suggestion. However what did you mean specifically with your last comment?>> With anything like this any time you save when building up the conditions >> will be dwarfed by the time it takes to run the actual queryOn 16 jul, 13:09, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Jul 16, 11:42 am, Jermaine <jermaine2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Hi everyone, > > > I have a working named_scope here, however it''s too cluttered. > > Anyone got a better (more efficient) and concise alternative? > > > Thanks. > > well named_scope :filter, lambda {|*args| > {:conditions => {:status => args.first, :invoice_number => > args.second}.reject{|k,v| v.blank?}} > > } > > is more compact and i think does the same thing as your code. With > anything like this any time you save when building up the conditions > will be dwarfed by the time it takes to run the actual query > > Fred > > > > > ===========================================> > named_scope :filter, lambda { |*args| > > if > > args.first && args.second == nil > > {} # return all records > > > if args.first.blank? > > { :conditions => ["status = ?", args.second] } > > > if > > args.second.blank? > > { :conditions => ["invoice_number= ?", args.first] } > > > else > > { :conditions => ["nvoice_number= ? and status = ?", > > args.first, args.second] } > > end > > end > > end > > }-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > Thanks for the suggestion. However what did you mean specifically with > your last comment? > > >> With anything like this any time you save when building up the > conditions > >> will be dwarfed by the time it takes to run the actual query >Putting words in Frederick''s mouth, but it simply means that it''s ridiculously quick to build up the conditions object in Ruby compared to actually executing the SQL on the database (and communicating the SQL and response over the socket). Cheers, Andy -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
aaah I-C. Okay thanks for clearing that up! great stuff On 16 jul, 14:16, Andy Jeffries <a...-4Fjv1yF9AWJvmwGHilWZ5bVCufUGDwFn@public.gmane.org> wrote:> > Thanks for the suggestion. However what did you mean specifically with > > your last comment? > > > >> With anything like this any time you save when building up the > > conditions > > >> will be dwarfed by the time it takes to run the actual query > > Putting words in Frederick''s mouth, but it simply means that it''s > ridiculously quick to build up the conditions object in Ruby compared to > actually executing the SQL on the database (and communicating the SQL and > response over the socket). > > Cheers, > > Andy-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
You might want to split those two into named_scopes of their own though - for more modularity and possible scope chaining opportunities elsewhere in the code. Handling whether one of those arguments, which I presume are user entered, is blank can be handled in the controller. On Jul 16, 5:32 pm, Jermaine <jermaine2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> aaah I-C. > Okay thanks for clearing that up! great stuff > > On 16 jul, 14:16, Andy Jeffries <a...-4Fjv1yF9AWJvmwGHilWZ5bVCufUGDwFn@public.gmane.org> wrote: > > > > > > Thanks for the suggestion. However what did you mean specifically with > > > your last comment? > > > > >> With anything like this any time you save when building up the > > > conditions > > > >> will be dwarfed by the time it takes to run the actual query > > > Putting words in Frederick''s mouth, but it simply means that it''s > > ridiculously quick to build up the conditions object in Ruby compared to > > actually executing the SQL on the database (and communicating the SQL and > > response over the socket). > > > Cheers, > > > Andy-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.