00:02
So whenever it comes to relationships, we have half of the picture taken care of. We have our IDs in place on our tables
00:10
that inform that one table relates via that ID to another table. For example, this user ID informs us that one row
00:18
inside of our profiles table relates to one particular user who has whatever ID is inside of this column for that row.
00:26
So if we have a profile row with a user ID of one, that profile row relates to the user with the ID of one. If the user ID is two, that profile relates to the user with an ID of two,
00:36
so on and so forth. And that's the database side of the relationship. We also have foreign keys in place to enforce data integrity so that we cannot relate to a user
00:43
that doesn't actually exist inside of the users table from our profile. But how does this relationship come into play whenever we start talking about the Lucid ORM?
00:52
It would be nice if we had the ability to work with our user record directly from our profile model instance and vice versa, be able to work with our profile
01:00
for whatever user model instance we are working with. Well, good news, that's actually how the Lucid ORM works whenever it comes to relationships. All that we need to do is inform it
01:08
what we want that relationship to be named and the applicable properties that the relationship should use to map that relationship together. I like to put all of my Lucid relationship definitions
01:18
down at the bottom of the model underneath our column properties. And this will look relatively similar to how we're declaring our columns, except it will use its own special decorators.
01:28
So here we have a profile with the user ID that belongs to a user record. So with that verbiage in mind,
01:35
we can define this relationship using @belongsTo, there's our decorator right there, and that's going to import from AdonisJS Lucid ORM.
01:44
And then inside of this belongsTo decorator, we're going to want to provide it an instance of our user model. So we'll provide this as a callback function
01:52
and then provide it a direct instance to our user model just like so. I tab to auto import that from our user model itself. And then we'll want to declare the property
02:00
that we want this relationship to be housed on. For this, it would make most sense to call this property user. And the type for this user is going to be belongsTo,
02:09
and this will be provided the type of our user model. And we're getting a red squiggly on our belongsTo, but that's because it wants it to be imported
02:16
with import type rather than a namespace import. So we'll scroll up and decorate this with type just like so, and everything should be A-okay. And you'll also notice that that imported
02:25
from AdonisJS Lucid types relations instead of AdonisLucid ORM. And that's it. That's how we define our relationship from our profile to our user.
02:34
Now, there are some defaults being applied here to make this work automatically for us. If we need to change those defaults at all, we can provide a second argument into the belongsTo decorator.
02:43
And you'll see that this is an option set of the type relation options. With belongsTo, the one that's going to apply is going to be the foreign key.
02:51
The foreign key with belongsTo is the relationship key that is on the model we're presently working with. So that's going to be our user ID.
02:58
So we can specify that in here just like so. However, our relationship is directly working with a model called user, and this model's primary key is ID.
03:08
And that's how AdonisJS is going to map the default for this foreign key altogether. So in turn, we are actually making use of the default already,
03:16
so we can keep things nice and clean and remove that just like so. So that will allow us to load in our user relationship whenever we're working with our profile model. Let's take care of the inverse side
03:26
so that we can work with our profile model from our user model as well. So let's jump over to our user model. We'll scroll down to the end of our model column declarations.
03:34
And our user profile relationship is a one-to-one type. So our profile belongs to one user and our user has one profile.
03:42
So anytime that the property of the relationship is on the model itself, that's where we'll want to use belongsTo. On the inverse side, we just need to describe
03:51
how many is expected to exist for that relationship. In this case, we expect it to have one. So we can decorate it with a decorator, noting that accordingly. And in this particular case,
04:00
that decorator is called as one. So we'll import that. And this works very similar to belongsTo. We provide it in a callback function that returns the related model.
04:09
In this case, that's going to be our profile model. We'll declare a property that we want this relationship to be housed on. And in this case, it would make most sense to call this our profile.
04:17
And we'll define it the type has one. That is a type of our profile model. Looks like the auto import for these relationships does not like to import with type.
04:27
So we'll go ahead and populate that on there as well. And now we'll be able to populate a profile directly for any user that we're working with from our user model. Just like with belongsTo, we could provide a second argument
04:36
to this has one decorator, which are option sets that allow us to define what this relationship should use to relate to one another. All of the other relationship decorators and types
04:46
are going to be the inverse of belongsTo. Where belongsTo, we were making use of the foreign key
04:52
to relate to the property that is on this particular model. So right here, our user ID is there. On all of the other relationship types,
05:00
the foreign key is going to relate to the profile that is on the relationship model. So in this case, our foreign key would be our user ID
05:08
that is existent on our profile model. So whenever you're working with a one-to-one relationship, the has one would use foreign key to specify the column that it would work with on the related model.
05:17
And belongsTo would specify the foreign key for the relationship column that it would work with on the current model that we are on. Again, though, with how we have everything set up, we can make use of just the defaults
05:27
since our model name is user and the primary key for that model is ID, and it will concatenate them together as such to comprise the default value for this relationship. So we're good there.
05:37
And the same thing is true with our has one decorator as well. The model that we're relating to is our user model and the primary key for that model is ID. So this too will use the default as well.
05:47
So we can get rid of that altogether there.
