I very often want to use dynamic finders to specify NOT NULL. So…
this works:
Widget.find_all_by_color('blue')
this works:
Widget.find_all_by_color(nil)
But how can I do
SELECT * FROM `widgets` WHERE `color` IS NOT NULL;
?
Two ways depending on how specific you want to be:
# in your model
class Widget < ActiveRecord::Base
# first way
named_scope :coloured, {:conditions => ["color IS NOT NULL"]}
# second way
named_scope :not_null, lambda{|*args| (field=args.first ? {:conditions => ["#{field} is not null",field]} : {}) } }
end
# in your controller
#coloured_widgets = Widget.coloured.all # using first way
#coloured_widgets = Widget.not_null(:colour).all # using second way
I hope it helps.
Cheers
Widget.find(:all, :conditions => "color IS NOT NULL")
Try this:
Widget.all(:conditions => "color IS NOT NULL")
Not quite as elegant, but this should work:
Widget.find(:all, :conditions => "'color' IS NOT NULL")
Related
Working on a webpage I used the next line:
Model.select(:column).where("column IS NOT NULL")
I was wondering if there was a more Rails-ish way to do this, like using a hash for example
Model.select(:column).where(column: !nil)
The Squeel gem will allow you to use != nil type syntax, but natively rails will not.
Example: Model.where{column != nil}
I would prefer to use a scope as its more readable as well as its more manageable later (like merging with other scopes)
class Model < ActiveRecord::Base
scope :not_null, lambda { |column|
{:select => column,
:conditions => "#{column} NOT NULL"
}
}
end
then use
Model.not_null("column_name")
In the Rails 4 you can do this:
Model.select(:column).where.not(column: nil)
In my Activity model, I have a default scope:
default_scope where(:subject_id => Log.get_subject_id)
Problem is in Log.get_subject_id, default value is 0. Here is my Log model:
##subject_id = 0
def self.set_subject_id(val)
##subject_id = val
end
def self.get_subject_id
##subject_id
end
When I change value of ##subject_id via Log.set_subject_id(10) in controller and then I try Activity.all, it always give me bad result. SQL:
SELECT "activities".* FROM "activities" WHERE "activities"."subject_id" = 0
Where is a problem? Thanks!
With that form of default_scope, your Log.get_subject_id call will be evaluated when the class is parsed so you're really saying something like this:
default_scope where(:subject_id => 0)
However, you can use a block with default_scope to delay the evaluation of the scope until you try to use it and, presumably, Log.get_subject_id will have a useful value:
default_scope { where(:subject_id => Log.get_subject_id) }
It is happening because of the scope caching, try wraping it with lambda:
default_scope lambda { { :conditions => { :subject_id => Log.get_subject_id } } }
I need to build a dynamic sql queue with 2 incoming params. It is easy when both params are defined.
MyClass.where(:column1 => param[:first], :column2 => params[:second])
but when for example param[:first] = 0 I want to select all(not null) fields for this column(so when both params are = 0 it would be equal to select * from tablename). Tried this syntax:
MyClass.where(:column1 => param[:first], :column2 => !nil)
but it gives me wrong output. Any suggestions how to elegantly resolve this?
You could use the ?: operator inside where:
MyClass.where(params[:first] ? {:column1 => params[:first]} : "column1 IS NOT NULL")
.where(params[:second] ? {:column2 => params[:second]} : "column2 IS NOT NULL")
What about MyClass.where('column1 IS NOT NULL AND column2 IS NOT NULL').where({:column1 => params[:first], :column2 => params[:second]}.delete_if{|k,v| v.nil?})?
I think this may work from what I've found. It appears to work in the rails console and considering active record alows active chaining:
MyClass.where(:column1 => params[:first], :column2 => params[:second]).where("column1 is NOT NULL").where("column2 is NOT NULL")
I'm building a user ranking system, and am trying to assign user.rank values with a name.
I wanted to define something like this in my User model and then be able to reference it when displaying each user's rank, but this probably isn't the best way:
class User < ActiveRecord::Base
RANK_NAMES = {
'Peasant' => (0..75),
'Craftsman' => (76..250),
'Vassal' => (251..750),
'Noble' => (750..1500),
'Monarch' => (1501..999999)
}
Perhaps it would be better to define a method in a controller or helper like:
if user.rank == 0..75
rank_name = "Peasant"
elsif...
But not sure how to do that. Anyone have any thoughts? I'm not even sure what to call what it is I'm trying to do, thus making it difficult to research on my own.
It could be something even as simple as this, assuming user.rank exists.
class User < ActiveRecord::Base
...
def rank_name
case self.rank
when 0..75
'Peasant'
when 76..250
'Craftsman'
when 251..750
'Vassal'
when 750..1500
'Noble'
when 1501..999999
'Monarch'
end
end
...
end
If rank_name is specific to the User, I'd make it a method of User.
You could try something like below. It might give you some ideas.
class User
RANKS = [
{:name => 'Peasant', :min => 0, :max => 75},
{:name => 'Craftsman', :min => 76, :max => 250}
# ...
]
attr_accessor :rank
def rank_name
# TODO what happens if rank is out of range of all ranks or rank is nil
# or not an integer
User::RANKS[rank_index][:name]
end
private
def rank_index
User::RANKS.index { |r| (r[:min]..r[:max]).include? #rank }
end
end
user = User.new
user.rank = 76
puts user.rank_name # -> Craftsman
I'm calling a pretty simple function, and can't seem to figure out whats going on. (I'm using rails 3.0.3 and the master branch of 'will_paginate' gem). I have the following code:
results = Article.search(params) # returns an array of articles
#search_results = results.paginate :page => params[:page], :per_page=>8, :order => order_clause
No matter what I make the order_clause (for example 'article_title desc' and 'article_title asc'), the results are always the same in the same order. So when I check using something like #search_results[0], the element is always the same. In my view, they are obviously always the same as well. Am I totally missing something?
I'm sure its something silly, but I've been banging my head against the wall all night. Any help would be much appreciated!
Edited to Add: The search clause does the following:
def self.search(params)
full_text_search(params[:query].to_s).
category_search(params[:article_category].blank? ? '' : params[:article_category][:name]).
payout_search(params[:payout_direction], params[:payout_value]).
length_search(params[:length_direction], params[:length_value]).
pending.
distinct.
all
end
where each of these guys is a searchlogic based function like this:
#scopes
scope :text_search, lambda {|query|
{
:joins => "INNER JOIN users ON users.id IN (articles.writer_id, articles.buyer_id)",
:conditions => ["(articles.article_title LIKE :query) OR
(articles.description LIKE :query) OR
(users.first_name LIKE :query) OR
(users.last_name LIKE :query)", { :query => "%#{query}%" }]
}
}
scope :distinct, :select => "distinct articles.*"
#methods
def self.payout_search(dir, val)
return no_op if val.blank?
send("payment_amount_#{dir.gsub(/\s+/,'').underscore}", val)
end
def self.length_search(dir, val)
return no_op if val.blank?
send("min_words_#{dir.gsub(/\s+/,'').underscore}", val)
end
Thanks.
If you look at the example from the will_paginate github page you can spot one important difference between their use of the :order clause and yours:
#posts = Post.paginate :page => params[:page], :order => 'created_at DESC'
This calls paginate on the Post object (with no objects being selected yet - no SQL has been executed before paginate comes along). This is different in your example: as you state in the first line of code "returns an array of articles". The simplest I can come up with showing the problem is
results = Model.limit(5).all
#results = results.paginate :order => :doesnt_matter_anymore
won't sort, but this will:
results = Model.limit(5)
#results = results.paginate :order => :matters
It should suffice to take the all out of the search method. It makes ActiveRecord actually perform the SQL query when calling this method. Will_paginate will do that for you when you call paginate (if you let it...). Check out the section on Lazy Loading in this post about Active Record Query Interface 3.0