Adding a User Search Feature in Rails with LIKE Queries 🔍

In my last post, I built a friend feature for my finance tracker app using a self-referential association so users can see what their friends are investing in. 📈

But there was one thing missing: before you can add a friend, you have to find them first. 🤔

So this post is about the feature that powers that. Letting users search for other users by name or email. And this time I did most of the work in the Rails console before writing a single line in the app.

Two ways to pass conditions to where

Hash condition for exact match:

User.where(email: 'samkim5869@example.com')
# → WHERE "users"."email" = '...'

String condition when you need patterns:

User.where("email like ?", 'samkim5869@example.com')
# → WHERE (email like '...')

Same value, same result. But the string form unlocks like. like is a SQL keyword, and Rails just hands the SQL inside that string straight to the database.

The % wildcard = "anything goes here"

User.where("first_name like ?", "Han%")   # starts with Han
User.where("first_name like ?", "%saem")  # ends with saem
User.where("first_name like ?", "%ansa%") # contains ansa

No % means exact match. With % it's partial. Really handy for filtering by domain:

User.where("email like ?", "%@example.com")
# → everyone whose email ends in @example.com

Building the search, piece by piece 🏗️

A generic engine: matches

def self.matches(field_name, param)
  where("#{field_name} like ?", "%#{param}%")
end

The self. makes it a class method so it's called as User.matches(...). Passing field_name as an argument means it can search any column.

The final window: search

def self.search(param)
  param.strip!
  first_name_matches(param)
    .or(last_name_matches(param))
    .or(email_matches(param))
end

strip! cleans whitespace off the search term (! means it mutates the original). .or Merges the three column searches into one result. So whatever the user types gets matched across first_name, last_name, or email. 🎯

Verifying in the console ✅

User.search('@').count
# → first_name like '%@%'
# → last_name  like '%@%'
# → email      like '%@%'
# => 3

Three queries fired, .or merged them, count came back. Logic confirmed before touching the app.

The takeaway: console then model then view

Last time I followed route ➡️ controller ➡️ view to build the friends page. This time the same discipline applied one layer earlier.

Skipping the console means: write code, boot server, open browser, type something, click, check, it’s wrong, fix it, repeat. Too many steps per check, and when something breaks you can’t tell if the query, the controller, or the view is at fault.

The console is one line = instant answer. It isolates the query logic so:

1. Console proves the query is correct
2. Model / controller is just wiring it up
3. View is just displaying it

When a bug shows up later, the scope is already narrow. It’s like tasting the dish as you cook instead of plating everything and then realizing it’s too salty. 🍳