WEBVTT 00:00.140 --> 00:05.910 So now let's go ahead and run Docker, compose up to start up all of our services and our MySQL server. 00:05.930 --> 00:12.920 So after all of our micro services have start up, let's go back to MySQL workbench and open up our 00:12.920 --> 00:15.650 connection to our database here. 00:15.650 --> 00:22.640 We can open up our sleeper schema and now we can see the autogenerated tables that type in Nestjs has 00:22.640 --> 00:23.930 created for us. 00:23.930 --> 00:30.230 We can start off by right clicking the reservation tables and listing out the schema here where we can 00:30.230 --> 00:36.440 see all of our schema and all of the properties that exist on our reservation with no data yet, we 00:36.440 --> 00:38.600 can do the same thing for a user. 00:38.600 --> 00:43.370 So if we select rows on a user, we see our ID, email and password. 00:43.400 --> 00:49.130 We don't see any relationship to the roles and that's because of the many to many relationship we have 00:49.130 --> 00:49.880 in place. 00:49.910 --> 00:55.670 We have a separate table here called Role that holds all of the roles. 00:55.670 --> 01:02.730 Since each role can be associated with many different users, we keep track of the roles here with an 01:02.730 --> 01:09.600 ID and name, and then there's a separate join table that we specified in our code that actually maps 01:09.600 --> 01:15.120 the user ID to that role ID and those relationships are held in this join table. 01:15.120 --> 01:22.200 So I have gone ahead and opened up Postman and let's launch a post request at localhost 3001, which 01:22.200 --> 01:24.150 is where our auth service is listening for. 01:24.180 --> 01:27.510 For Http requests slash users. 01:27.540 --> 01:33.000 I'll create a new user with an email password and let's create a new role. 01:33.000 --> 01:37.970 So to create a new role, we'll only provide the name and I'll create an admin role. 01:37.980 --> 01:40.410 So we'll go ahead and send this request. 01:40.410 --> 01:48.330 And now we can see I have a newly created user with my auto incremented ID here back in MySQL workbench. 01:48.360 --> 01:55.560 If we're execute the query for the users, we can see our user in the database here and if we look for 01:55.560 --> 01:59.150 the roles, we can now see the newly created admin role. 01:59.160 --> 02:00.990 Now, importantly, the join table. 02:00.990 --> 02:06.420 If we query this one, we see this mapping between user ID one and role ID one. 02:06.420 --> 02:09.000 So this is where that relationship is held. 02:09.000 --> 02:14.550 So let's say we wanted to create a different user with a different email and we wanted to reference 02:14.550 --> 02:15.600 that same role. 02:15.600 --> 02:20.130 We would just provide the ID of that role, which in this case is one. 02:20.130 --> 02:28.500 Now if we send off this user to be created and query the users table again, we can see the newly created 02:28.500 --> 02:29.460 user here. 02:29.460 --> 02:35.910 But now if we query the role table again, we see we still only have that admin role because we were 02:35.910 --> 02:43.020 referencing it with our ID and the type ORM cascades are smart enough to know that we want to reference 02:43.020 --> 02:44.850 this role here and now. 02:44.850 --> 02:50.850 If we look at the join table, we should see this new relationship being recorded here with user ID 02:50.880 --> 02:54.540 two referencing role ID one our admin role. 02:55.110 --> 02:57.210 So let's log in with this user. 02:57.240 --> 03:03.240 I'll launch a post request at auth slash login and we have our JWT cookie set. 03:03.240 --> 03:10.050 So now we are authenticated and now if we call get slash users, we can see we get our user back with 03:10.050 --> 03:14.700 our email password and ID, but we don't have the roles being listed here. 03:14.700 --> 03:21.660 And that's because by default type ORM and Nestjs won't populate these relations that we have set up 03:21.660 --> 03:22.680 on the entity. 03:22.710 --> 03:26.520 We have to specifically specify when we want this to happen. 03:26.520 --> 03:33.330 So in order to implement this Intel type ORM that we want all of our Cascade relations to be populated, 03:33.330 --> 03:41.250 we'll go back into our abstract repository where we'll accept an optional second parameter called relations 03:41.250 --> 03:49.230 that's of type, find options relations, and we pass in our generic type T, We can then pass this 03:49.230 --> 03:52.500 directly in to the find one call. 03:52.650 --> 03:58.830 And so now if we go back to the user service, we'll pass in an options object which contains all the 03:58.830 --> 04:00.990 relations we want to be populated. 04:00.990 --> 04:05.520 So we will just say that we want our roles to be true. 04:05.520 --> 04:11.970 So now we'll get the user's roles when we ask for them because we have our cascade linked to this property 04:11.970 --> 04:13.250 on the entity. 04:13.260 --> 04:18.900 So now if I launch a get request for this user, I can see the roles for it being populated, which 04:18.900 --> 04:21.910 is our admin role thanks to our join table. 04:21.930 --> 04:27.510 Next, let's go ahead and try creating a new reservation, so I'll launch a post request at localhost 04:27.510 --> 04:33.300 3000, slash reservations and send off the expected body that we've used before. 04:33.510 --> 04:40.530 So if I send this, we can now see that we have a reservation sent back with an ID of one and we can 04:40.530 --> 04:48.150 go ahead and try to query this to get it back by ID of one for our single get request here, we can 04:48.150 --> 04:54.660 look in the database as well by querying the reservations table and seeing our whole reservation. 04:54.810 --> 04:58.230 Let's also go ahead and try launching a patch request. 04:58.230 --> 04:59.880 So let's change the end date. 04:59.900 --> 05:04.940 For this reservation and say it will now end on the ninth instead. 05:05.240 --> 05:12.080 We'll send this patch request and we can see the end date was updated and now we can launch a get and 05:12.080 --> 05:14.510 see it remains on the ninth. 05:15.270 --> 05:17.730 Finally, let's try our delete method out. 05:17.730 --> 05:21.150 So if I send this delete call, we have a 200. 05:21.300 --> 05:25.190 And now if I get all reservations, we should expect to see none left. 05:25.200 --> 05:31.260 So now we can see how we've easily implemented more Crud functionality with an entire different database 05:31.260 --> 05:33.490 thanks to our abstract repository. 05:33.510 --> 05:38.970 This was a lot easier to do because we only had to change our data access code in one spot.