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
01. Introduction
02. One to one
03. One to many
04. Belongs to
05. Eager loading
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
08. Has one through
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.
33 episodes•4 hrs 18 mins•1 year ago
Overview
Eloquent is Laravel's ORM (Object Relational Mapper). In simple terms, it's how your models work with the database.
The good news? There's a bunch of powerful relationship types available. Our task is to learn when and where to use each one.
In this course, we'll cover each basic relationship type, how to access related models, and then insert, sync, update and delete related data. Oh, and we'll build a practical example for each relationship type, to really make it stick.
Alex Garrett-Smith
Hey, I'm the founder of Codecourse!
Comments
No comments, yet. Be the first to leave a comment.