So now let's go ahead and run Docker, compose up to start up all of our services and our MySQL server.
So after all of our micro services have start up, let's go back to MySQL workbench and open up our
connection to our database here.
We can open up our sleeper schema and now we can see the autogenerated tables that type in Nestjs has
created for us.
We can start off by right clicking the reservation tables and listing out the schema here where we can
see all of our schema and all of the properties that exist on our reservation with no data yet, we
can do the same thing for a user.
So if we select rows on a user, we see our ID, email and password.
We don't see any relationship to the roles and that's because of the many to many relationship we have
in place.
We have a separate table here called Role that holds all of the roles.
Since each role can be associated with many different users, we keep track of the roles here with an
ID and name, and then there's a separate join table that we specified in our code that actually maps
the user ID to that role ID and those relationships are held in this join table.
So I have gone ahead and opened up Postman and let's launch a post request at localhost 3001, which
is where our auth service is listening for.
For Http requests slash users.
I'll create a new user with an email password and let's create a new role.
So to create a new role, we'll only provide the name and I'll create an admin role.
So we'll go ahead and send this request.
And now we can see I have a newly created user with my auto incremented ID here back in MySQL workbench.
If we're execute the query for the users, we can see our user in the database here and if we look for
the roles, we can now see the newly created admin role.
Now, importantly, the join table.
If we query this one, we see this mapping between user ID one and role ID one.
So this is where that relationship is held.
So let's say we wanted to create a different user with a different email and we wanted to reference
that same role.
We would just provide the ID of that role, which in this case is one.
Now if we send off this user to be created and query the users table again, we can see the newly created
user here.
But now if we query the role table again, we see we still only have that admin role because we were
referencing it with our ID and the type ORM cascades are smart enough to know that we want to reference
this role here and now.
If we look at the join table, we should see this new relationship being recorded here with user ID
two referencing role ID one our admin role.
So let's log in with this user.
I'll launch a post request at auth slash login and we have our JWT cookie set.
So now we are authenticated and now if we call get slash users, we can see we get our user back with
our email password and ID, but we don't have the roles being listed here.
And that's because by default type ORM and Nestjs won't populate these relations that we have set up
on the entity.
We have to specifically specify when we want this to happen.
So in order to implement this Intel type ORM that we want all of our Cascade relations to be populated,
we'll go back into our abstract repository where we'll accept an optional second parameter called relations
that's of type, find options relations, and we pass in our generic type T, We can then pass this
directly in to the find one call.
And so now if we go back to the user service, we'll pass in an options object which contains all the
relations we want to be populated.
So we will just say that we want our roles to be true.
So now we'll get the user's roles when we ask for them because we have our cascade linked to this property
on the entity.
So now if I launch a get request for this user, I can see the roles for it being populated, which
is our admin role thanks to our join table.
Next, let's go ahead and try creating a new reservation, so I'll launch a post request at localhost
3000, slash reservations and send off the expected body that we've used before.
So if I send this, we can now see that we have a reservation sent back with an ID of one and we can
go ahead and try to query this to get it back by ID of one for our single get request here, we can
look in the database as well by querying the reservations table and seeing our whole reservation.
Let's also go ahead and try launching a patch request.
So let's change the end date.
For this reservation and say it will now end on the ninth instead.
We'll send this patch request and we can see the end date was updated and now we can launch a get and
see it remains on the ninth.
Finally, let's try our delete method out.
So if I send this delete call, we have a 200.
And now if I get all reservations, we should expect to see none left.
So now we can see how we've easily implemented more Crud functionality with an entire different database
thanks to our abstract repository.
This was a lot easier to do because we only had to change our data access code in one spot.