Question

Using Ruby on Rails combined with capistrano and git, I’ve run into an annoying problem..

I have a controller “people” with the index action that looks something like this:

def index
  @people = Person.find( :conditions => params[:search] )
end

There is a boolean “is_admin” column in the Person table. Assuming that some of the people are admin and some are not, a get call to http://localhost:3000/people?search%5Bis_admin%5D=true should populate @people with some users… And this is true for my local pc when I run the app in development mode..

But…. When I deploy to my server account ( railsplayground ), a call to http://mydomain.com/people?search%5Bis_admin%5D=true fails to find any matching items.
However, if I change …?search[is_admin]=true to …?search[is_admin]=1 the response returns the administrator users as expected…

Back on my local pc, the use of “1” instead of “true” fails.

The bottom line is that

Person.find( :all, :conditions => { :is_admin => 'true' } )

works my development environment, and

Person.find( :all, :conditions => { :is_admin => 1 } )

works in my deployed environment.

Why is this? and how can I fix it?

Ideally I would like to place links like:

link_to( "Administrators", {
  :controller => '/people',
  :action => :index,
  :search => { :is_admin => true }
})

and get a lists of administrators :).

Might be worthy to note that my development database is a sqlite3 file, and production is a mysql database…

EDIT: I understand the objections to user-input, but in this exceptional case it is a very very minor threat. Also, my current code works perfectly in either my development pc, or my production account, but not on both. The easiest sollution seems to change the way sqlite3 saves and interperets boolean values, so I would change my question to “how do I change the way sqlite saves boolean values”… If sqlite would mimic mysql’s behavior perfectly, it would serve my developments needs perfectly…

Answer 1

The problem is that you are passing a boolean value as string and the final behavior depends on the active database. Here’s a more detailed explanation.

When you read the params[:search] variable, the content is a string and there’s no type. This is because the query string can’t understand whether

params[:search][:is_admin] = "true"

actually means

params[:search][:is_admin] = "true"
params[:search][:is_admin] = true

Likewise, when you pass 1 you end up with

params[:search][:is_admin] = "1"

which is different than

params[:search][:is_admin] = 1

When you pass the value to the query, because you are not passing a boolean, the value is not translated by the database adapter. Your final query result in something like

SELECT * FROM `persons` WHERE `persons.is_admin` = 'true'

SQLite3 stores boolean as t/f strings. true is stored as 't' and false is stored as 'f'. I guess it also understands true/false and it automatically translates your query.
On the opposite, MySQL understands only 0/1 and true/false and it fails.

When you switch the behavior, passing 1 instead of true, you are causing SQLite to fail because it can’t translate the string "1" to 't'. On the opposite, MySQL can and it does.

In both case, you are doing it wrong. You shouldn’t pass a string but a boolean value. Also, you should never trust user input.

My suggestion is to normalize your params[:search] before feeding Person.find.