Rails 6.1 Upgrade? Beware the where.not() Conundrum!

Upgrading a Rails app is like opening a mystery box—you never quite know what surprise awaits you inside. Recently, I took the plunge from Rails 4 to Rails 6.1, and boy, did I stumble upon a puzzler: our good old friend, where.not(), suddenly decided to play hard-to-get.

The Mystery Unfolds: where.not() and the Vanishing Results

In Rails 4, where.not() with multiple arguments was the reliable sidekick every developer wished for. You’d throw in a couple of conditions, and it would smoothly filter out the unwanted records. Simple, effective, no drama.

But Rails 6.1 had other plans. Suddenly, where.not() seemed to forget how to handle multiple arguments. Instead of returning the expected results, it left me scratching my head, wondering if I’d accidentally switched to an alternate reality. ??

The Plot Twist: NOR vs. NAND—Rails 6.1 Changes the Game

Here’s where things get really interesting. Since Rails 6.1, where.not() has changed its behavior from applying a NOR (NOT(A) AND NOT(B)) logic to a NAND (NOT(A) OR NOT(B)) logic when used with multiple attributes. If you’re not careful, this subtle change can drastically alter your results, potentially pulling in more records than you intended.

Let’s break it down with an example:

Before Rails 6.1 (NOR Logic):

# Don't send newsletters neither to admins nor to trashed users!
users = User.where.not(role: 'admin', trashed: true)
# SQL generated:
# => "SELECT "users".* FROM "users" WHERE "users"."role" != 'admin' AND "users"."trashed" != TRUE"
        

After Rails 6.1 (NAND Logic):

# Suddenly, you're sending newsletters to trashed admins!
users = User.where.not(role: 'admin', trashed: true)
# SQL generated:
# => "SELECT "users".* FROM "users" WHERE NOT ("users"."role" = 'admin' AND "users"."trashed" = TRUE)"
        

As you can see, the behavior shift from NOR to NAND means that instead of excluding records where both conditions are true, Rails 6.1 now excludes records where either condition is true, which could lead to a much larger matched set.

The Detective Work: Cracking the Case with .where.not().where.not()

The solution? You now have to repeat yourself with .where.not().where.not() to achieve the old NOR logic:

# Use this query to keep applying NOR
users = User.where.not(role: 'admin').where.not(trashed: true)
# SQL generated:
# => "SELECT "users".* FROM "users" WHERE "users"."role" != 'admin' AND "users"."trashed" != TRUE"
        

It’s a bit like Rails 6.1 saying, “I’ll do what you want, but only if you ask nicely… and then ask again.” ??

Visualizing the Change: NOR vs. NAND

Imagine the logic as a Venn diagram where the left circle represents "admins" and the right circle represents "trashed users." In the NOR scenario, the red area would be the intersection of both circles, where neither condition is true. In the NAND scenario, the red area would be everything outside the intersection—catching cases where at least one condition is false.

The Takeaway: Embrace the Quirks, and Grow with the Challenge

Upgrading Rails isn’t just about tapping into the new shiny features; it’s also about embracing the quirks and surprises that come along. Every hiccup is a chance to learn, adapt, and refine your skills. And hey, if you’re a fan of mystery and adventure, upgrading Rails is the perfect playground.

Remember, every challenge you face makes you a stronger, more resilient developer. So, when Rails 6.1 throws you a curveball with where.not(), smile, refactor, and keep moving forward. The more you dive into these quirks, the better you become.

Why Should You Care?

If you’re a Rails developer who loves digging deep, solving puzzles, and improving your craft, this is the kind of experience that builds your expertise. Don’t shy away from the challenge—embrace it. And if you’re on the fence about upgrading, just know that the journey, quirks and all, is worth it.

#RORXray #RailsUpgrade #RubyOnRails #Rails61 #DeveloperJourney #CodingChallenges