Eloquent Relationships By Example
This episode is for members only

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

Get started
Already a member? Sign in to continue
Playing
17. Switching up keys

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
7m 28s
0%
02. One to one
02. Creating and accessing the relationship
12m 1s
0%
03. Creating an address
5m 47s
0%
04. Updating an address
1m 49s
0%
05. Deleting an address
1m 6s
0%
06. Scoping to get the most recent address
5m 42s
0%
07. Building a working example
24m 34s
0%
03. One to many
08. Defining one to many relationships
5m 25s
0%
09. Two ways to insert
5m 10s
0%
10. Accessing the relationship data
11m 53s
0%
11. Deleting records
8m 19s
0%
12. Updating records
2m 9s
0%
13. Adding modifiers directly to the relationship
4m 50s
0%
14. Creating a postable timeline app
19m 38s
0%
04. Belongs to
15. Defining a belongs to relationship
10m 34s
0%
16. Associating relations
6m 4s
0%
17. Switching up keys
4m 16s
0%
05. Eager loading
18. Debugging the issue
3m 59s
0%
19. Eager loading
4m 10s
0%
06. Many to many
20. Defining many to many relationships
13m 46s
0%
21. Attaching relations
8m 58s
0%
22. Detaching relations
1m 52s
0%
23. Attaching and detaching multiple relations
3m 58s
0%
24. Eager loading
2m 15s
0%
25. Defining the inverse of the relationship
7m 40s
0%
26. Intermediate table columns
7m 54s
0%
27. Filtering by intermediate columns
8m 16s
0%
28. Syncing relations
7m 19s
0%
07. Has many through
29. Defining and using has many through relationships
15m 43s
0%
08. Has one through
30. Using has one through relationships
15m 54s
0%
09. Has one of many
31. Setting up a practical example
5m 13s
0%
32. Defining and using a has one of many relationship
10m 6s
0%
33. Using aggregate functions
5m 5s
0%

Transcript

00:00
One more thing that we're going to look at here, which applies to pretty much any eloquent relationship type is the ability to specify different keys, if this varies within your database. So, so far, what we've been doing when we've been, say, creating our post table is we've been using Laravel's convention. Now, Laravel's convention will take a singular version of the plural version of your table. So users, obviously the single here is user, and this is the primary key on the users table.
00:31
So it will be user underscore ID. Now, if this varies for any reason, you can specify these in any pretty much any relationship type you create within Laravel. So we're going to go ahead and change this over manually within our database just so we don't have to modify our migration. And we're going to see how this varies.
00:51
So let's go over to our database and manually change over the user ID column to something completely different and just see what happens. So let's think of a good example here, because it's really difficult not to keep convention. Let's just change this to person ID, although it kind of doesn't make sense. Let's save that out and just see what happens when we go over here and give this a refresh.
01:15
OK, so the first thing that we see is attempt to read property name on null. This basically means that within our template, user is now null. That's because behind the scenes, Laravel does not know by its convention how to grab the user for a post. So we're going to need to change the relationship over on post to figure out how we specify this.
01:38
So we do this by passing a second, potentially third argument into it. So the first thing is the foreign key. Let's go ahead and provide this in here now. So for the foreign key, if we just head over here, the foreign key is now person ID.
01:54
And we're going to look into the users table in a minute to see what the third argument is, if that is different as well. So we're going to go ahead and put person ID inside of there. Now, for the third argument, owner key is implicitly set to ID. So we're going to kind of leave that for now.
02:11
Let's go over and give this a refresh. And you can see this is now working. So if you do have a column name that varies, then it's very easy just to go ahead and supply that as the second argument just here. Now, if for some reason over on the users table, ID was completely different or you needed to specify something completely different in here, then you can change that as well.
02:33
So let's just roll with a really silly example. I'm going to call this the ID, the underscore ID. Of course, when we head over to our app, we know that this is going to break and we get a little bit more of a useful error here. And this is an SQL error coming directly from the database.
02:48
Column users.id does not exist. We know that's the case because we have switched that over. So now what we can do is the third argument, the owner's key, which is the user, we can supply that as the ID. So we know that that now gets hooked up.
03:02
So regardless of how your database is set up, Laravel's relationships will allow you to define out the keys that they use to access this. Now, in the example of this being a belongs to relationship or even a has many relationship or has one relationship, these are pretty straightforward. But as you get to more complex relationships a little bit later on in the course, these can be specified. But of course, there are a lot more.
03:27
So, for example, when we look at things like has many through or any polymorphic relationships, these are going to massively vary. So I'd always recommend sticking with the conventions. So I'm going to go ahead and get rid of these now. I'm going to change the ID back to ID.
03:43
So it actually makes sense. And I'm going to change this over to user ID. So it's really important to try and stick with the conventions. If you're building out an app from scratch, if you have a database that you're porting over from, say, a legacy application that doesn't use Laravel,
03:59
then, of course, you're going to want to probably just define these in your relationships. You might also have a really good reason to change around the column name. So it makes a little bit more sense for your schema. But of course, you know now that you can change around any of the keys that Laravel uses.

Episode summary

In this episode, we explore how you can switch up the key names used in your Eloquent relationships, which comes in handy if your database doesn't use Laravel's default conventions.

Usually, Laravel expects keys like user_id for foreign keys and id for primary keys. But sometimes, maybe your database uses different names—maybe you're working with a legacy database or you just have your own conventions. We'll go into our database and manually mess around with the key names (changing user_id to something like person_id for example) and see what impact that has. Spoiler: things break initially because Laravel can't find the right keys!

But don't worry, we fix it by explicitly telling Laravel what the new foreign key is, and show how you can also specify a custom owner key. There's even a quick example where both foreign and primary keys get custom names, and we see how to make it all work again.

We wrap up by talking about why it's generally a good idea to stick to Laravel's defaults unless you have a specific reason not to—but now you know exactly what to do if you ever need to change them.

Episode discussion

No comments, yet. Be the first!