DEV Community: SakuraMilkTea

.present? VS .any? VS .exists?

SakuraMilkTea — Sun, 30 Jun 2024 15:13:49 +0000

Something I have a difficult time wrapping my head around as a newbie is how actually super important it is to care about query speeds.
Different methods will have vastly different query speeds, and it's therefore to my advantage to understand how they actually work, in order to use the one that will do what I want while keep everything running smooth.

Here are three methods I've been using recently that kind of look the same, but run differently in the background and therefore have different uses!

.present?

[ "", " ", false, nil, [], {} ].any?(&:present?)
# => false

This one tests for an object's general falsiness. As per the documentation, "An object is present if it’s not blank?. An object is blank if it’s false, empty, or a whitespace string."
Very important to point out that .present? initializes ActiveRecord for each record found(!). It effectively goes through the whole relevant database available.

.any?

person.pets.count # => 0
person.pets.any?  # => false

This one will use a SQLCount to see if it's > 0, and therefore, although faster than .present?, still takes time and queries the database multiple times.

.exists?

Note.create(:title => 'Hello, world.', :body => 'Nothing more for now...')
Note.exists?(1) # => true

This one, according to the documentation, "asserts the existence of a resource, returning true if the resource is found."
The beauty of .exists? is that it uses SQL LIMIT 1 to just check if there's at least one record, without loading them all or counting them all!
In a case where I just want to know if an object is there or not, this is without a doubt the best option.

And now to remember these three...

Let's do our best!

Interesting Things I learned Writing Rspec Tests

SakuraMilkTea — Thu, 27 Jun 2024 14:24:35 +0000

Writing test code is good form and is obviously always recommended. Writing GOOD test is an excellent way to fool-proof the code you (I) have so far, but like everything else, it takes practice!

In an attempt to keep it fresh in my mind, here are a few things I found out recently about writing rspec code...

travel_to is useful... But only allowed once.

Okay. That was a bit dramatic. You can actually use travel_to in separate blocks as much as you want.

context "first context" do
  travel_to("2024-12-25") do
    expect(presents)
  end
end

context "second context" do
  travel_to("2024-12-31") do
    expect(fireworks)
  end
end

However, you're (I am) not allowed to do some magical shenanigans such as this

context "first context" do
  travel_to("2024-12-25") do
    expect(presents)

    travel_to("2024-12-31") do
      expect(fireworks)
    end
  end
end

Not only does it look weird and messy, but also you'll get a big angry error. So yeah.
However in some cases it will be inevitable for the whole file to be enclosed in a travel_to for some reason or other. And that's when it's a good idea to use travel_back!

context "first context" do
  travel_to("2024-12-25") do
    expect(presents)

  context "second context" do
    before do
      travel_back
    end
    travel_to("2024-12-31") do
      expect(fireworks)
    end
  end
  end
end

Simple? Yes. But does it do a good job? Also yes.

Update: I have learned an even better method today. The trick is simply to not make subsequent travel_to into blocks!

context "first context" do
  travel_to("2024-12-25") do
    expect(presents)

    travel_to("2024-12-31")
    expect(fireworks)
  end
end

It's better to not write DSLs dynamically

This one might come as a surprise for some, because it sure did for me. Consider this example

describe 'some spec' do
  (1..7).each do |n|
    let!(:"user_#{n}") { create(:user, name: "user#{n}") } 
  end
  # ...
end

I thought I was super clever to use iteration like that, but learned from reviewers that it's not good practice. Although it saves time and works fine, it's not reader-friendly.
Instead, a very similar approach can be used through FactoryBot

describe 'some spec' do
  let!(:users) { FactoryBot.create_list(:user, 7) } 
  # ...
end

This obviously assumes that the name is set in the FactoryBot file

FactoryBot.define do
  factory :user do
    sequence(:name) { |n| "user#{n}" }
    # ...
  end
end

As I become more acquainted with rspec and keep writing more code, I might come back and edit this document with more interesting finds ☺︎

Let's keep doing our best!

A newbie's look at N+1 queries

SakuraMilkTea — Thu, 27 Jun 2024 12:41:56 +0000

N+1 queries usually happen when there is a one-to-many relationship, where we (I) try to call a record related to an object that is the child(many) of the main parent(one) object.

Let's use for this article an Author(one) and her books(many).

If you're not sure whether it IS an N+1 problem query or not, check your log (bin/dev).
You'll know you have an N+1 error when your parent object is loaded fine, but then underneath you'll have a bunch of children object loaded separately from one another, back-to-back.

So in our example, you'd see first that you'd be loading the author.

SELECT "author" FROM "authors" WHERE "authors"."id" IN "Fantasy" AND "books"."published blablabla"

That's fine, but then the problem arises when you see something like this after.

SELECT "book" FROM "books" WHERE "books"."id" blablabla ["id", 4]
SELECT "book" FROM "books" WHERE "books"."id" blablabla ["id", 7]
SELECT "book" FROM "books" WHERE "books"."id" blablabla ["id", 9]
SELECT "book" FROM "books" WHERE "books"."id" blablabla ["id", 11]
SELECT "book" FROM "books" WHERE "books"."id" blablabla ["id", 15]
...etc

So over and over again we're loading these books, and each time we do that, we're making a request to the database. Sure, that's not a big deal in my example because we made 5 requests, but it does start to become an issue when authors or author groups have hundreds of books. Publishing houses that have tens of thousands. Obviously this wouldn't be a good way to go about getting that data.

The solution to this lies in the controller, where we are selecting the data, and on how we include the author data in our book query... See what I did there?

We are telling Rails that we want to run just one statement to select all that related data at once, instead of running multiple individual statements for each individual record later.

@books = Book.includes(:author).order(published_at: :desc)

Looking back at our log, we should see something like this

SELECT "book" FROM "books" WHERE "books"."id" blablabla [["id", 4], ["id", 7], ["id", 9], ["id", 11], ["id", 15]]

It's really good form to go back in your logs and look at how your data is being loaded, and where the load is coming from in your application's code! ☺︎

And for when we need a little extra help, there are always neat gems like this one

Let's keep doing our best!