Eloquent Relationships By Example

Sign in Get started

This episode is for members only

Sign up to access "Eloquent Relationships By Example" right now.

Already a member? Sign in to continue

Playing

18. Debugging the issue

Episodes

0%

Your progress

Total: 4h 18m
Played: 0m
Remaining: 4h 18m

Join or sign in to track your progress

01. Introduction

01. Installation, database and migration refresher

02. One to one

02. Creating and accessing the relationship

03. Creating an address

04. Updating an address

05. Deleting an address

06. Scoping to get the most recent address

07. Building a working example

03. One to many

08. Defining one to many relationships

09. Two ways to insert

10. Accessing the relationship data

11. Deleting records

12. Updating records

13. Adding modifiers directly to the relationship

14. Creating a postable timeline app

04. Belongs to

15. Defining a belongs to relationship

16. Associating relations

17. Switching up keys

05. Eager loading

18. Debugging the issue

19. Eager loading

06. Many to many

20. Defining many to many relationships

21. Attaching relations

22. Detaching relations

23. Attaching and detaching multiple relations

24. Eager loading

25. Defining the inverse of the relationship

26. Intermediate table columns

27. Filtering by intermediate columns

28. Syncing relations

07. Has many through

29. Defining and using has many through relationships

08. Has one through

30. Using has one through relationships

09. Has one of many

31. Setting up a practical example

32. Defining and using a has one of many relationship

33. Using aggregate functions

Transcript

00:00

Before we carry on with the rest of the course, it's really important to cover eager loading,

00:03

because this can get you into a lot of trouble with the performance of your applications as more data starts to roll in. Now, we're going to use the same code that we used for the belongs to course or section of the course, because this is where the problem starts to come in. So I have a new project. I have all of the same code in here where we are listing through all

00:23

of the posts in the database and, of course, showing who posted these posts. So what we're going to do in this episode is, first of all, look at the problem by installing a package called Laravel debug bar. I'll walk you through what is actually happening. And in the next episode, we will look at solving the problem. So the first thing I'm actually going to do is head over to the

00:48

index file, so index.blade.php under our post. And I'm going to get rid of the line. I'm actually going to delete this that tells us who posted this. And we're going to go ahead and install the debug bar, see the queries that are running, and then pull that line back to see what happens. So to go ahead and install Laravel debug bar, we're going to come over to the GitHub repository

01:10

and we're going to come down to the composer install command here and basically just paste this into our project and let that run. Now, this is very easy to set up. In fact, we don't really need to do anything. We just need to come back over to our application, give the page a refresh, and you'll notice that we have a nice toolbar at the bottom, which will give us the amount of

01:30

queries that are being run, the amount of views that are being rendered. But we're going to focus on this queries tab. Now, at the moment, as you would expect, we have one query, which kind of makes sense. We're just grabbing all of these posts. We are ordering them by creating that in descending order. Remember, we added that to actually order these and that is pretty much it.

01:53

So, so far, everything looks good. One database query to fetch the data and we're iterating through it. Let's go over now and bring back that line where we are accessing now the user that owns each of these posts. So let's come over to our page here, give this a refresh. And for some reason, this is bumped now up to eight queries. So we're running eight queries just to get a list of our

02:20

posts. Now, what's actually happening here is a problem called an N plus one problem where for every single post, N, we are adding an additional query or doing something additionally. In our case, it's just adding an additional query. So if we head over to our database here under posts, let's access the content, you can see here we've got seven posts. This kind of makes sense. We have

02:48

an initial query to grab all of the posts, but now for every single post that we have, which is seven, we're adding an additional query, which of course brings us up to eight total queries. This is not what we want to happen. Let me show you why. So if I go ahead and add a new post to the database, so let's say manually created post, another manually created post, doesn't really

03:15

matter what it says. And I attach this to user one and save this out. Let's give that a refresh. And we've bumped up to nine. So what is happening here is that every single new post now we are adding an additional query. So if we had 100 posts on this page, we are going to end up with 101 queries because we have that initial query to fetch all of them and then 100 to fetch every

03:42

single user. Even if they're the same user, we're fetching these in an additional query. This is not what we want. As our app grows and as more data rolls in, it's going to cause a massive issue. So let's head over to the next episode now that we can actually debug this and figure out a solution.

Episode summary

In this episode, we dive into a super common performance issue in Laravel apps—known as the N+1 query problem. Before moving forward in the course, we take a moment to really understand what eager loading is and why not using it properly can slow your application to a crawl as more data shows up.

We start by reusing the code from earlier in the course (listing posts and showing the user who posted each), but before fixing anything, we install the Laravel Debugbar package to see what's really happening behind the scenes. After installation, we walk through how Debugbar works and use it to monitor the queries our app runs when loading the posts page.

At first, everything looks fine—just a single query. But as soon as we add back the line that displays the user for each post, Debugbar shows our query count jumping up: now every post triggers its own database query to fetch the user! We walk through adding more posts and see the query count keep climbing, making it clear how this gets out of hand as your data grows.

We explain why this happens (the N+1 problem), look at the impact with more data, and set things up so that in the next episode, we can jump in and actually fix the issue. By the end, you’ll know what to look for, how to spot it, and be ready to see the solution in action next time.

Episode discussion

No comments, yet. Be the first!