🕑 Chapters:
- Intro
- Relationship Types
- AdonisJS Relationship Lookup
- AdonisJS Relationship Decorators
- Belongs To (one-to-one)
- Has One (one-to-one)
- Relation Configuration Options
- Belongs To (many-to-one)
- Has Many (many-to-one)
- Relationship Model Names
- Many To Many
- Pivot Table & Pivot Columns
- Outro
📜 Transcript:
so the reason that we saved
relationships in our models as one of
the last things here to Define within
our models is because they kind of work
differently from the remainder of the
columns that we've defined so far we've
defined everything that actually exists
within our database we all of these are
valid columns if we were to go look
within our database they have column
representations there the actual
relationship definitions though we're
going to serve as more of a virtual
definition and they have lookups that
look up to the particular IDs that
define those relationships and the way
that we Define these varies slightly
depending on what particular
relationship type it is so we have one
to one one to many many to one and then
many to many within our existing schema
over here on the right hand side I do
have those to find out within a key down
at the bottom I'm going to go ahead and
expand this out so on the lines pointing
to the specific relationship definitions
I've marked it as one to one for one to
one one to M for one to many M to one
for minute one and then M to M for many
to many now the difference between one
to many and many to one differs
depending on what side of the
relationship you're looking on so I've
pointed all of these in the same
direction so that all of our one to many
and many to one are defined as the same
so here you can see we have a role ID
pointing to our roles table from our
users table that's defined as M to 1 as
many to one instead of one to many
whereas if we were to go the other way
then that would become a one to many so
in terms of those two it's just
depending on what side of the
relationship you're starting from and
pointing to similar to how I have this
key noting out the different
relationship pipes here we also need to
do the exact same thing within our model
to tell Adonis what type of relationship
it is that we're working with so that
they know how to look it up accordingly
so let's go and collapse this down and
just like with the actual columns how
it's differed from camel case to snake
case there are specific lookups that
Adonis is going to look for as the
default naming convention within our
profile column here we have this user ID
now the way Adonis is going to look this
user ID relationship up by default
whenever we actually Define this
relationship is this going to take the
relationship model name and then it's
going to take the primary key for that
model and snake case it together so it's
going to be user underscore ID that it
would look for because the user model is
the model that that column is relating
to and ID is the primary key so here we
have a match with the actual default
naming convention for Adonis so the way
that we would Define this is if we look
over at our key this is a one-to-one
relationship our users are always going
to have one profile and our profiles are
always going to belong to one user so in
terms of our Lucid models we're going to
want to Define both sides of those
relationships so that we have both sides
to work with you can Define just one
side if you know that there's one side
you're never going to work with but I
prefer to Define both because you never
know when it might come in handy later
down the road and the way that we Define
these relationships just like with all
of our column definitions is via
decorators so there's a different
decorator per relationship type that we
have within our model in a really great
spot to find all of the different
decorators for the relationships is
within the documentation if you go into
references the database scroll down on
the left hand side you'll see
relationships here and you'll see has
one has many belongs to many to many and
then has many through now we're not
going to be focusing on as many through
quite yet we'll save that for a later
point in time but with our specific
schema we do have a relationship for
each one of these four has one has many
belongs to a many to many which one to
use here in your particular use case can
be kind of confusing for people
especially if you're not used to the
terminology here the easiest way to
remember it here if we dive back into
our profile if the column actually
exists on the model in most cases that
will be a belongs to because our profile
belongs to the specific user ID so we
can Define this within this model here
by doing at belongs to and then we
provide in the actual model that this is
related to so we do this as a callback
function let's import our user model
here then just like all of our other
columns here we want to do public give
this relationship a name we can do user
and then the type for this is going to
be belongs to let's open this up type of
and then the user so if I scroll up just
a little bit here you can see we have
our user ID on our profile model now we
also have a user relationship which
serves as kind of a virtual
representation of what a actual user Is
So within our profile model we already
have everything done this is our
perfectly valid relationship definition
all we need to do from here is query and
work with it but we do want to go on the
inverse side of this relationship on our
user and also Define it there because we
don't know whether or not we need to
populate the profile from the user side
or from the profile side so we want it
to be available from both sides so that
we can work with it either way so let's
jump over to our user model scroll down
since there's no profile ID on the
actual model here this isn't going to be
it belongs to it's going to be a has one
because a user has one profile so we can
do at as one provide this a callback of
type profile and this will point the
actual relationship to our profile model
do public profile and then we want to
define the type here as has one type of
profile and so now we have both sides of
the relationship defined so whenever we
go to query this we can query a user
with a profile or we can query a profile
with its attached user either way it
works so there's an example of a
one-to-one relationship definition
within adonisjs on one side we have a
has one and then on the other side we
have a belongs two because this is the
side that has the actual referencing of
the ID for the relationship and the way
that the Donis is going to look up up
the ID value here is based off of the
relationship definition so it's going to
take the model and it's going to lower
case that and it's going to concatenate
that with the primary key of that
related model so in this case it would
be user underscore ID and that's how it
would look up the column definition
within the actual database and the
actual column value for our user ID up
here is the exact same it's user
underscore ID so the two match up
perfectly in the case that they didn't
there is that additional option set
within this belongs to has one has many
and many to many all of them have it
they do very differently depending on
what type of relationship definition it
is but they all have this additional
option set where we could define
specific column values in case anything
doesn't match up one to one with the
default naming structure of Adonis and
again the best place to find all
different relationship options is within
the documentation within the reference
under database you can scroll on down to
decorators where you have all of the
different decorators that we have
defined here so if you look at has one
you can see right here we have our has
one example with a profile if we scroll
down we have all of the different
options that we can provide into this so
we have the foreign key the local key
serialize as and on query callbacks that
we can Define on this particular
relationship the foreign key and local
key are the two different options that
you have in this particular relationship
definition when it comes to how Donna
should look up what particular column it
should find for a particular
relationship so you have form key for
one side of the relationship and local
key for the other side of the
relationship so you can Define the two
different columns that you should use
for the relationship look up there and
then you have serialize which changes
the actual column name and how it's
serialized the same as with the column
decorator then you also have on query
which allows us to Define additional
always existing query definitions
whenever we go to query the actual
column and this is really powerful and
allows us to Define specifics if we want
to define a relationship specifically
for a set type so say maybe with our
many many relationship with our posts
and our topics if we always wanted our
topic to query public posts we could
Define that within the on query images
always happen anytime that we query our
posts from our topic cool so we have one
relationship definition done let's go
ahead and move on to some of the others
how about we do a mini to one next let's
do our user and our role so let's go
back into our user model and this is
another case where we have a specific ID
on the user model now despite this being
a many to one instead of a one to one
since the ID is still on this model it
still belongs to definition so we can
scroll down to the bottom do at belongs
to provide us a callback to our role
model public role and the type will be
belongs to type of role so there's one
side let's jump over to our role model
and on this side since a role can have
many users this would be a has many
relationship so we could do at has many
provide this a callback with the user
model since this is the relating model
do public users has many type of user
and there we go there's our many to one
relationship example done now we do have
a couple more of those within this
project so let's go ahead and Define
those out before we move on to many to
many so we also have a post that belongs
to many users so let's go ahead and
Define that out so let's jump into our
post model here again this is another
one where it has that ID on it so in
this case it's going to be belongs to so
we can scroll down to the bottom do at
belongs 2 provide that our user model
public user belongs to type of user now
in this particular use case whenever we
go to add our user onto our posts via
querying it may not make complete sense
to us what exactly the user is so it
might make more sense to name this
something different something more
meaningful for our relationship name
here so since we actually have the model
bound to the relationship the model is
what's going to be used to find that
actual column name and the actual name
of the relationship or free to name
whatever we desire so here instead of
user we're free to name this something
like author if we so wish and whenever
we go to query that later on we can use
that reference name of author in order
to preload our author onto our posts in
which case that might be more meaningful
than preloading a user onto a post
instead we can preload an author so you
have that option available to you as
well so we can go ahead and give that a
save jump over to the other side so we
have that user side and over here our
users can have many posts so this would
be a has mini so we do at has many host
public posts has many type of and there
we go there's that relationship
definition done now on our post we do
have one more additional belongs to and
that's for our state ID so we can go
ahead and Define that up as well so this
would be at belongs to state public
State belongs to type of state and we go
ahead and jump into our state model and
Define that relationship there as well a
state can have many posts so this would
be a at has many post public posts as
many type of posts there we go and now
all that that leaves us is our post to
topic many to many relationships so for
this specific relationship we do have
this post topic pivot table that we'll
want to go through in order to bind this
relationship together and if you
remember there's a specific many-to-many
decorator that allows us to do that
without needing to define a specific
model for that post user table so let's
jump into our post side first and let's
get this to find out so we have an at
many to many just like all of the others
we wanted to find this to the particular
model that is bound to on the inverse
side of the many to many skipping over
that pivot table so in this case it
would be our topic scroll up a little
bit here this would be public topics
Mini 2 mini type of topic so really
looks the exact same as all of the
others but whenever it comes to the
actual option set there is a little bit
more to it so let's dive into the
documentation set take a look at it so
you can go back within the reference
database scroll down to the orms section
where decorators is come over on this
page to many to many and you can see
each one of these options here along
with a definition so since there's two
different sides to this relationship
you're going to have two different sets
of keys you can Define so you have the
four in which is one side and then you
have the local which is the other so
pivot foreign key is going to be one
side pivot related form key is going to
be the other then you have local key and
related key which are two different
sides as well and if you ever get
confused or needed an example whenever
you're looking this up on the Fly you
can get within guides scroll down to the
orm section go underneath relationships
come over here on the right hand side
the mini the mini and you'll get an
example so here within the example you
have users and skills Bound by a skill
user pivot table if you scroll down just
a brief bit it goes over what each one
of these Keys represents with that
example so just know that that does
exist exist on the documentation if you
ever get confused on which is which
there a great way to bypass all of that
is just use the default naming
Convention of Adonis because that's what
we've done here and we can just leave
this relationship definition as is and
everything will work out of the box with
no issues but if you do ever need to
provide those in here just provide a
secondary argument of those relationship
options and they'll work just fine there
are a couple of additional ones that we
haven't covered yet called pivot table
and that's going to be the table name of
the actual pivot table so in our case
it's going to be post topic and the way
that it'll find that is just binds two
model names together and snake case and
that's the default naming convention
that we've gone with here so we don't
need to Define that here but there is an
additional one of pivot columns and
these are columns that will be included
from the pivot table anytime that we
query these relationships so in our case
we do have one of those we have that
sort order and the way that we can
Finance this via an array and we just
need to define the actual column name
there to include with it so if we want
that included every single time that we
read these two relationships we want to
include that on both sides of that
relationship so that it will be
automatically included you can also omit
that here and Define to include it in
any particular one query on the query in
itself so you have the two different
options there on how to include those
intermediary table columns in our use
case I'll go ahead and leave it here so
that you know that that does exist so
let's go and jump back over to the
opposite side here so we have our post
done now we need to do our topic side
and this is just going to look the exact
same everything's just going to be flip
flop so we have our mini to mini this
will be bound to our post public posts
mini to mini type of post again we also
have all of those same options available
here everything is just flip-flop
value-wise but we do want to Define that
pivot columns as sort order so that's
available anytime that we query and
there we have it so all of our
relationship definitions are done we're
good to move on to crud work in the next
lesson if you enjoyed this lesson or you
learned something new please consider
hitting the like button down below and
subscribing future lessons just like
this one as I just stated we're going to
move on to credward next with our
different models and then we'll move
into relationship cred work after that
so thanks for sticking around everybody
I'll see you all in the next one
[Music]