WEBVTT 00:00.120 --> 00:02.280 Hello everyone and welcome back. 00:02.280 --> 00:08.280 In this lesson we're going to learn how to define nested relationships in our serialized classes as 00:08.280 --> 00:09.120 an example. 00:09.120 --> 00:15.720 We're going to extend our news API project by creating a new journalist model that we're going to bind 00:15.780 --> 00:21.780 to our article more than we've a foreign key field instead of a charter field that we're currently using. 00:21.780 --> 00:27.690 We're going to learn how to define for each side of the relationship and for each instance a list of 00:27.690 --> 00:30.770 primary keys or strings of related objects. 00:30.960 --> 00:36.660 All the details of a specific instance or an automatically generated a bit link to the corresponding 00:36.660 --> 00:38.170 end point. 00:38.190 --> 00:43.890 We're also going to talk about went to actually make those relationships explicit by providing all the 00:43.890 --> 00:46.020 details of the instances involved. 00:46.200 --> 00:51.190 I went to opt for other design choices based on the development context instead. 00:51.300 --> 00:52.230 Let's get started. 00:53.320 --> 00:53.710 Okay. 00:53.760 --> 00:59.790 So here we are in Visual Studio code and as you can see I've currently opened the Model S dot by file 01:00.150 --> 01:07.110 because we need to create the journalist model first so that we can bind it to the article model in 01:07.110 --> 01:10.670 order to make some examples of nested relationships. 01:10.680 --> 01:12.330 This is going to be pretty easy. 01:12.960 --> 01:24.600 So class journalism models that model and this model is going to have three fields first name which 01:24.600 --> 01:35.700 is going to be our field so models not char field with max length 16 then it's going to have a last 01:35.700 --> 01:49.530 name field and a biography field models dot text field with black true so that we can make this field 01:49.590 --> 01:53.880 optional that we need to define it down the string method. 01:53.880 --> 02:08.420 So self return we can use a formatted string literal so self got first name. 02:08.530 --> 02:16.850 So Dan we can add the last name as well okay. 02:16.900 --> 02:20.980 We now need to create the relationship between the two models. 02:21.040 --> 02:28.580 So I'm going to comment out the author field like so and yeah I'm going to define author models dot 02:29.120 --> 02:34.150 for a key and I'm going to point to journalist 02:36.960 --> 02:47.760 with on delete model dot skate and we can also specify a related name parameters so the related name 02:48.030 --> 02:54.700 equals articles and I can just as well delete these comments. 02:55.350 --> 03:00.810 So let's create our migrations new terminal like so. 03:00.960 --> 03:03.390 So Python manage that by 03:06.190 --> 03:14.800 make migrations so create model journalist alter field offer on article before we give them migrate 03:14.880 --> 03:15.520 command. 03:15.540 --> 03:20.300 There is one thing that we need to take into consideration considering that we've just after to the 03:20.310 --> 03:27.060 field author on article which was previously our field and now with key applying their migrations on 03:27.060 --> 03:34.620 our current database would result in errors trying to access the previously created article instances 03:35.070 --> 03:41.910 we could have in fact specify the default parameter for our field or we could have deleted the previously 03:41.910 --> 03:45.510 created article the instances before altering the model. 03:45.540 --> 03:51.780 But another thing that we can just as well do is to delete our database applying all the new migrations 03:51.840 --> 03:56.100 afterwards or a newly created one which is what we're going to do. 03:56.100 --> 04:01.740 This is clearly something that you do not want to do in production of course but if we can still afford 04:01.740 --> 04:02.970 it is perfectly fine. 04:02.980 --> 04:13.760 So remove database that sequel line 3 and now Python managed that by migrate going to create new Subarus 04:13.760 --> 04:19.670 the python manage that by create super user admin 04:23.360 --> 04:28.290 we can now register the new modelling to add me note by file journalist 04:34.300 --> 04:38.300 to so let's run a development server now 04:41.340 --> 04:43.630 and let's open up google chrome. 04:43.980 --> 04:48.360 So going to go to slash admin 04:52.350 --> 04:55.410 I'm going to create an instance of a journalist first. 04:55.410 --> 05:06.370 So John Peter Time Traveller save let's create an article for instance. 05:06.670 --> 05:11.100 So author John teeter title. 05:11.350 --> 05:25.450 This is the first article we are publishing description first article of the new database. 05:25.600 --> 05:34.780 Here we can just write some content like so location you can say Rome publication date today flagged 05:34.870 --> 05:37.910 as active save and add another. 05:37.980 --> 05:49.870 So either this is our second article and maybe a couple of characters more so maybe drastic article 05:50.560 --> 06:03.820 random description random content location can say Milan publication date today save. 06:04.240 --> 06:11.000 So let's not go and have a look at our API is actually representing the relationship between the generalist 06:11.000 --> 06:13.210 model and the article model. 06:13.210 --> 06:23.260 So let's go to slash API is Lesh articles and it is our list of articles in case you're wondering time 06:23.260 --> 06:31.130 since publication says 16 hours because as you can see at the moment is almost 16 PM. 06:31.480 --> 06:36.260 So let's leave that aside for a moment and let's focus on the author field instead. 06:36.340 --> 06:43.660 As you can see by default the relationship is expressed using the primary key of the related object. 06:44.110 --> 06:50.100 So we go to Jason with all the details of an article ESD and we go a specific field. 06:50.140 --> 06:55.540 The author field which is is the primary key of the related object as its value. 06:55.570 --> 06:57.910 Let's see how we can spice things up a little bit. 06:58.030 --> 07:02.250 For example by showing the name of the author instead of its primary key. 07:02.350 --> 07:12.200 So let's go back to visual studio code in the serialized is done by file and here in the article sterilizer 07:12.690 --> 07:14.880 we can not specify the name of the field. 07:14.910 --> 07:15.780 So author 07:18.450 --> 07:23.530 equals realizes dot string related field. 07:23.730 --> 07:29.450 Let's restart our development server and let's go back to Chrome. 07:29.530 --> 07:30.820 Right away. 07:30.820 --> 07:32.600 Let's make another get request. 07:33.580 --> 07:39.440 And as we can see the relationship is now expressed using a string which represents the name of the 07:39.460 --> 07:47.840 offer to be precise the relationship is expressed using what we've defined in the down the string method. 07:47.920 --> 07:54.310 Let's now go back to these to your code and let's see how we can actually use another sterilizer to 07:54.310 --> 07:58.480 represent all the data of the related object in our sterilizer. 07:58.510 --> 08:03.850 Basically we're going to use another serialize it to sterilize the data of the deleted object. 08:03.850 --> 08:07.860 We need to create our journalists utilize their first. 08:07.980 --> 08:12.490 So Plus journalist 08:15.220 --> 08:28.490 sterilizer realizes that model C that I said So class Meta model equals journalist which we actually 08:28.580 --> 08:40.400 need to import like so that we can just say that we want to use all the fields of the model like so 08:41.480 --> 08:44.780 now we can't take the name of a serialized. 08:45.260 --> 08:55.280 I can just comment is filled out so I can define author as journalists sterilizer and we actually need 08:55.280 --> 09:01.980 to move the class right here on top like so. 09:02.090 --> 09:10.050 So let's restart that development server and let's go back to Chrome and let's make right away now they'll 09:10.060 --> 09:11.540 get the request. 09:12.040 --> 09:12.660 Also. 09:12.670 --> 09:13.420 Perfect. 09:13.420 --> 09:20.860 We now get another Jason with all the details of the Hoffer for each single article instance in this 09:20.860 --> 09:26.530 could prove to be in fact really helpful because at the moment we do not need to make any other request 09:26.530 --> 09:29.010 to get all the details of the author. 09:29.020 --> 09:34.120 However there are some drawbacks which we must take into account when creating our API. 09:34.360 --> 09:43.650 For example let's try to create a new article the instance going to delete all the unnecessary fields. 09:45.360 --> 09:48.210 And the hot Fairfield in the time since publication. 09:48.870 --> 09:54.400 So this is another article. 09:54.700 --> 09:59.950 Yet another awesome title. 10:00.160 --> 10:07.200 So let's try and create this new article and you see we get an error age GDP 400 bed request author. 10:07.330 --> 10:09.160 This field is required. 10:09.160 --> 10:18.190 We could go ahead and you know try to work around the limitation by specifying read only through. 10:18.550 --> 10:27.200 So I'm now going to refresh our development server let's try to create the article once again so I'm 10:27.200 --> 10:29.140 going to the proper end point. 10:30.310 --> 10:32.810 Like so post. 10:32.860 --> 10:35.220 And of course we now get another kind of error. 10:35.230 --> 10:43.240 So integrity error not a normal constraint failed news article not author idea because in fact we cannot 10:43.240 --> 10:49.060 create an article without a journalist because journalists are those who write articles. 10:49.060 --> 10:52.980 Therefore we necessarily need them in this particular context. 10:53.020 --> 10:58.700 A better design choice could be to make the relationship explicit from within the journalist serialized. 10:58.960 --> 11:06.770 So let's go back to visual studio code and dear I'm just going to comment this out and I'm going to 11:06.770 --> 11:12.130 move the class right below like so. 11:12.220 --> 11:21.040 Indira I'm going to define articles equals where I'm going to use article sterilizer and I'm going to 11:21.040 --> 11:30.130 pass read only equals through so that we can keep the opportunity of creating new journalistic instances 11:30.490 --> 11:33.700 without having to pass an article least all the time. 11:33.750 --> 11:41.380 Other parameter that I need to pass is many equals true because this you realize there is going to be 11:41.380 --> 11:43.860 used to serialize the whole query set. 11:44.110 --> 11:50.090 We now need to create a new view to actually show a list with all the journalists. 11:50.230 --> 11:56.150 So I'm going to import the model journalist and the sterilizer journalist. 11:56.440 --> 12:11.630 I can just copy to name like so so right here below and I can also comment to can move them. 12:13.350 --> 12:15.230 On the bottom of the page like so. 12:15.400 --> 12:22.420 So I'm going to fix the code one two and I can now create the new view. 12:23.460 --> 12:32.400 I'm going to use the API view class to create this view so class journalist list create the API view 12:33.480 --> 12:34.450 API view. 12:36.450 --> 12:43.480 And yet I can just copy and decode that I've used for the article least create API view. 12:43.750 --> 12:50.450 So this is going to be journalist equalizer here and here. 12:50.900 --> 12:57.590 And this is going to be journalists which also need to best Let's utilize it. 12:58.210 --> 13:07.490 And this is going to be the journalists Modo like that even though the query it is going to be different 13:07.520 --> 13:11.370 because this time I want to have all the journalists. 13:11.430 --> 13:15.850 Now we need to connect our view to it you et end point. 13:15.890 --> 13:17.690 So I'm going to added to our tuple 13:21.540 --> 13:28.750 so I can copy this and find like so and is going to be journalists 13:32.120 --> 13:40.040 journalists at least create TPA view Germany's list and we're now ready to check out and you end point 13:40.070 --> 13:44.070 so I can restart the development server. 13:44.130 --> 13:44.670 Perfect. 13:44.790 --> 13:47.550 Let's go back to Chrome India. 13:47.580 --> 13:51.870 We can now go to slash API slash journalists 13:55.210 --> 13:59.950 awesome as you can see we now get to least with all the journalists in our database even though at the 13:59.950 --> 14:01.680 moment we only have one instance. 14:01.870 --> 14:09.610 But more importantly we see that now we get to list we've all the articles that are related to a specific 14:09.610 --> 14:15.740 journalist and we can also create new instances without any problems. 14:15.750 --> 14:26.870 So let's try to create and you weren't going to delete everything up to the idea like so maybe we can 14:28.030 --> 14:40.480 sense and do something like Johnny Cash and biography so run don't text so let's create a new instance 14:40.750 --> 14:41.300 post. 14:41.920 --> 14:46.460 And it is perfect as you can see we get no problems this time. 14:46.780 --> 14:52.510 And right away we see that we got a list of articles even though the list is empty and we can clearly 14:53.350 --> 14:59.920 have a look at at least and point and edit is a second journalist instance. 15:00.670 --> 15:07.220 Another way to express nested relationships within are serialized this involves the use of the IP or 15:07.210 --> 15:10.630 linked related field as we have briefly mentioned. 15:10.630 --> 15:17.600 This is a field that allows us to get a direct link to the proper endpoint for a specific resource. 15:17.770 --> 15:24.890 We can set up an IP link related field like so let's go back to the serialize is not by file and yet 15:24.910 --> 15:34.270 for example we can just specify particles equals serialize there's not hyper linked related field just 15:34.270 --> 15:40.900 going to comment this out like so and yet do we need to define three parameters. 15:41.050 --> 15:52.180 First of all many equals true then read only it was true and then we need to specify view name which 15:52.180 --> 16:00.610 in fact represents the name of the view basically of the real end point that we want to use to actually 16:00.610 --> 16:03.280 generate automatically these hyperlinks. 16:03.850 --> 16:09.520 So in this case I'm going to use the article detail name which is clearly the name associated to the 16:09.520 --> 16:14.250 article detail API you end point and using this name. 16:14.250 --> 16:20.860 Indeed I believe the related field which results in us getting automatically a URL to the article detail 16:20.890 --> 16:27.160 end point which is going to give us the details of this specific article instance litigating the link 16:27.160 --> 16:27.920 for. 16:27.940 --> 16:30.300 So let's go back to the serialized thought by file. 16:30.470 --> 16:33.430 I'm just going to pass article detail perfect. 16:33.460 --> 16:35.350 There is one last thing that we need to do. 16:35.380 --> 16:41.710 Because the way the hyperlink related field works we need to specify another parameter to pass to our 16:42.230 --> 16:53.620 serialized class and this parameter is context which we're going to use to pass the request to our sterilizer. 16:53.650 --> 17:00.920 So now that everything is done we can restart our development server so let us go back to Chrome let's 17:00.920 --> 17:02.580 make another get request. 17:02.930 --> 17:08.510 And as you can see we now get to least we have all the other points that are associated to the details 17:08.570 --> 17:10.590 of a specific critical instance. 17:10.850 --> 17:16.670 We can now make a get request the Words the specific endpoint and this way we can easily get all the 17:16.670 --> 17:18.800 details of our articles. 17:18.860 --> 17:25.370 So this is how you make nested relationships explicit within serialized sets in Django framework as 17:25.370 --> 17:31.130 you can see there are several ways that we can do so and potentially we could add more for example by 17:31.130 --> 17:38.810 creating another specific serialized or to use let's say in the detail end points another pretty common 17:38.810 --> 17:45.970 way to do things is to just leave that primary key as value associated to the related object and then 17:45.980 --> 17:50.990 make a get request each and every time you need some details about the specific instance you're working 17:50.990 --> 17:51.560 with. 17:51.620 --> 17:56.900 So that was really it for this lesson about the nested relationships in the next video I'm going to 17:56.900 --> 18:00.930 introduce you to the competency assessment project for Django framework level 1. 18:00.980 --> 18:01.480 See you there.