1 00:00:00,570 --> 00:00:06,360 In the last section we looked at an example of how to update a survey that I would call kind of a bad 2 00:00:06,360 --> 00:00:08,800 approach or an inefficient approach. 3 00:00:08,900 --> 00:00:13,410 It would have definitely worked out but it would have been doing a lot more work than we actually needed 4 00:00:13,410 --> 00:00:17,440 to do between the Express server and our Mago database. 5 00:00:17,460 --> 00:00:23,190 We're now going to continue by figuring out how to write a far more compact query that is going to find 6 00:00:23,190 --> 00:00:26,680 an update just the survey that we really care about. 7 00:00:26,700 --> 00:00:28,030 So let's get to it. 8 00:00:28,080 --> 00:00:32,790 Now the first thing I want to do is I want to remind you once again that after we process all of our 9 00:00:32,790 --> 00:00:37,300 different events coming from grid we end up with an object that looks like this right here. 10 00:00:37,350 --> 00:00:41,190 So we've got survey ID email and the choice properties. 11 00:00:41,190 --> 00:00:44,080 Now I want to kind of look at this object right here. 12 00:00:44,250 --> 00:00:49,470 I want to think about how all of our actual surveys look inside of our database and then figure out 13 00:00:49,470 --> 00:00:55,110 if we can't point out like a couple of different properties from this subject right here and compare 14 00:00:55,110 --> 00:00:59,250 it to some of the different properties that we want to actually look up inside of our data. 15 00:00:59,250 --> 00:01:05,910 In other words given an object like this right here what properties do I need to look at on my survey 16 00:01:05,970 --> 00:01:12,420 records in my Mongo database in my surveys collection to make sure that I am finding the exactly correct 17 00:01:12,510 --> 00:01:13,460 survey. 18 00:01:13,920 --> 00:01:14,190 All right. 19 00:01:14,190 --> 00:01:15,730 So let's take a look at this. 20 00:01:15,780 --> 00:01:19,670 So we're going to say given any event of this right here. 21 00:01:19,770 --> 00:01:28,650 So a survey of 4 5 6 an email of a at a dot com and a choice of yes exactly what records inside of my 22 00:01:28,650 --> 00:01:30,590 database do I want to update. 23 00:01:30,690 --> 00:01:36,700 So I've listed out two possible records that I've gotten side of my surveys collection inside of Mongo. 24 00:01:36,950 --> 00:01:39,290 So you can see that every survey has an ID. 25 00:01:39,400 --> 00:01:44,240 The sub document collection of recipients and the yes and no properties over here as well. 26 00:01:45,060 --> 00:01:47,800 Now of course the survey has many other records as well. 27 00:01:47,970 --> 00:01:53,130 But right now these are kind of the only properties that we really care about as far as kind of finding 28 00:01:53,220 --> 00:01:55,310 and updating the correct survey goes. 29 00:01:55,320 --> 00:02:00,630 So let's walk through the logic of exactly what we really care about inside of our query to make sure 30 00:02:00,630 --> 00:02:05,730 that we find and update only the surveys that we really truly care about. 31 00:02:05,730 --> 00:02:07,650 So we're going to look at this property by property. 32 00:02:07,650 --> 00:02:13,940 We're going to say first off OK of course we want to find the survey with a given ID like that's the 33 00:02:13,950 --> 00:02:14,480 guarantee. 34 00:02:14,490 --> 00:02:17,470 Without a doubt we want to find the survey with a given ID. 35 00:02:17,820 --> 00:02:24,000 So when I look at this first survey right here I see that it has an I.D. of 4 of 1 2 3 which clearly 36 00:02:24,000 --> 00:02:26,730 does not match up to 4 5 6. 37 00:02:26,790 --> 00:02:31,870 So pretty much from the get go we know without a doubt we don't care about this survey right here. 38 00:02:31,920 --> 00:02:35,230 We don't care about it so we're going to kind of throw it out the window. 39 00:02:35,400 --> 00:02:36,880 So let's go down to the next survey. 40 00:02:36,910 --> 00:02:41,250 And again we are pretending that these are both records inside of our service collection. 41 00:02:41,250 --> 00:02:45,380 Now this survey Yeah it definitely has an idea of 4 5 6. 42 00:02:45,390 --> 00:02:46,950 Now here's the trick. 43 00:02:46,950 --> 00:02:50,460 Before we just say oh OK it has a matching survey. 44 00:02:50,450 --> 00:02:52,710 This must be the one that we want to update. 45 00:02:52,740 --> 00:02:55,090 This must be the one that we want to care about. 46 00:02:55,110 --> 00:02:56,820 That's not exactly what we're going to do. 47 00:02:56,820 --> 00:03:05,820 We're going to write a query where we say find a survey that has not only the correct I.D. but also 48 00:03:05,820 --> 00:03:14,100 has a recipient with this given e-mail and has not yet responded or has responded property of false. 49 00:03:14,100 --> 00:03:18,840 So in other words I want to find not just this survey because it has an idea of four or five six but 50 00:03:18,870 --> 00:03:24,900 I want to make sure that this survey right here also has a record in its recipient some document collection 51 00:03:25,320 --> 00:03:28,550 with an email of a at a dot.com. 52 00:03:28,710 --> 00:03:34,230 And I want to make sure that that recipient has responded false to our given surveys so they've never 53 00:03:34,230 --> 00:03:36,140 given feedback before. 54 00:03:36,870 --> 00:03:40,760 So I would want to look into this recipients of document collection. 55 00:03:41,010 --> 00:03:46,410 I would say OK here's a recipient they've got an e-mail of DIA dot dotcom and they've already responded. 56 00:03:46,470 --> 00:03:49,580 So no this is not a record I care about yet. 57 00:03:49,830 --> 00:03:52,110 I didn't look at the next recipient side the list. 58 00:03:52,250 --> 00:03:57,290 And I notice that it has an e-mail of a EYKAMP and it has responded false. 59 00:03:57,420 --> 00:04:00,530 And so clearly this recipient right here matches my criteria. 60 00:04:00,540 --> 00:04:06,840 I had wanted to find someone with an email of a dot.com who had not yet responded to the survey. 61 00:04:06,930 --> 00:04:13,770 And so after correlating or kind of checking the id property the email property and the respondent property 62 00:04:13,830 --> 00:04:19,530 I would then say OK clearly this is in fact the survey that I want to find and the one that I want to 63 00:04:19,530 --> 00:04:26,100 update now as I start to as i'm like saying this stuff you might be sitting there thinking well wait 64 00:04:26,100 --> 00:04:27,770 a minute what's this about the recipient. 65 00:04:27,780 --> 00:04:32,370 Why can't we just assume that hey you got a survey idea four five six. 66 00:04:32,370 --> 00:04:34,920 Clearly this is the one you care about right here. 67 00:04:34,920 --> 00:04:41,370 Well what I'm saying is that if we can write some type of query that attempts to find a record with 68 00:04:42,090 --> 00:04:50,850 the id the given e-mail and respondent property are false then we can write a query that lets Mongo 69 00:04:50,880 --> 00:04:57,330 execute all of this search logic for us and you and I should never actually have to take the survey 70 00:04:57,690 --> 00:04:59,690 and pull it back into the No. 71 00:04:59,720 --> 00:05:00,300 Yes world. 72 00:05:00,300 --> 00:05:06,330 In other words we can write a query that is executed entirely inside of the Mongo database and never 73 00:05:06,330 --> 00:05:11,640 once requires us to actually load any data back over to the Express side of our application. 74 00:05:11,730 --> 00:05:16,860 And so that would solve all the issues that I was just talking about with this other kind of junky query 75 00:05:16,860 --> 00:05:22,190 over here where we were loading up not only a survey but the entire list of recipients. 76 00:05:22,200 --> 00:05:26,630 So we are pulling all this data from Mongo over to the Express side of the world. 77 00:05:26,640 --> 00:05:32,730 So what I'm suggesting here is that if we consider not only the ID property in our search criteria but 78 00:05:32,760 --> 00:05:38,640 also the email and responded properties then we can write a single query that will always return exactly 79 00:05:38,640 --> 00:05:41,040 just the data that we really truly care about. 80 00:05:42,670 --> 00:05:50,200 Now I want to give you a quick example here what would happen if I put responded of true in here instead. 81 00:05:50,290 --> 00:05:55,210 So we said that OK this person has the e-mail but they have already responded to the survey. 82 00:05:55,480 --> 00:05:59,260 So now if we start to think about the same exact query that we were just talking about let's kind of 83 00:05:59,260 --> 00:06:01,500 walk through it on this record right here. 84 00:06:01,690 --> 00:06:06,630 We would say OK it's got the correct survey ID 4 5 6 6. 85 00:06:06,640 --> 00:06:13,590 Now does it have an email of a at a dot com for one of the recipients would say OK that's DRDO dot com 86 00:06:13,600 --> 00:06:14,860 we don't care about that one. 87 00:06:14,980 --> 00:06:16,470 Oh here it is at a dot com. 88 00:06:16,480 --> 00:06:18,660 So it's a yep that fits our criteria. 89 00:06:18,730 --> 00:06:25,550 And now the very last piece of criteria does that same record have a responded property of false. 90 00:06:25,690 --> 00:06:27,790 Well no it doesn't anymore now it has responded. 91 00:06:27,790 --> 00:06:29,230 Property of true. 92 00:06:29,290 --> 00:06:34,700 And so we would say oh this survey right here it does not actually match our search criteria. 93 00:06:34,720 --> 00:06:39,580 This must not be a survey that we are actually truly carrying or that we actually truly care about. 94 00:06:39,580 --> 00:06:44,290 So let's go and look at the next survey and see if maybe that one matches. 95 00:06:44,290 --> 00:06:50,290 So clearly if we just look at all three properties for figure out which survey we need to update we 96 00:06:50,290 --> 00:06:57,080 can kind of include or we can kind of disqualify any surveys that don't have the correct three properties. 97 00:06:57,160 --> 00:06:59,660 Now at this point I'm kind of talking myself into a circle here. 98 00:06:59,680 --> 00:07:03,770 As you can kind of tell I as a quick Editor's note here. 99 00:07:04,330 --> 00:07:09,700 I want to tell you that whenever you're figuring out these really complex Mongo queries life is kind 100 00:07:09,700 --> 00:07:15,520 of tough and I'm trying to give you a little bit of a walkthrough of giving you just like at least a 101 00:07:15,520 --> 00:07:20,950 hint of an idea of how you kind of approach writing these queries after we actually write the code around 102 00:07:20,950 --> 00:07:21,510 this. 103 00:07:21,550 --> 00:07:26,740 I'm gonna show you a method that you can use to kind of arrive at this logic of how we write all these 104 00:07:26,740 --> 00:07:29,220 queries out much more easily than you know. 105 00:07:29,230 --> 00:07:33,540 I'm kind of trying to describe it to you and the words I can give you a little bit of a toolbox or a 106 00:07:33,540 --> 00:07:38,460 tool set for putting queries together that do all this update logic efficiently. 107 00:07:38,900 --> 00:07:39,360 OK. 108 00:07:39,370 --> 00:07:44,140 So I think I've kind of you know again spoken myself into a corner here with all this update logic stuff. 109 00:07:44,380 --> 00:07:49,450 I want to say let's just flip over to our code editor let's try to write out some type of query that 110 00:07:49,450 --> 00:07:55,120 will take a given event like this thing right here and then tried to find the appropriate survey to 111 00:07:55,120 --> 00:07:56,140 update. 112 00:07:56,140 --> 00:08:02,310 So we flip on over to my code editor and I don't really care about writing this code inside of our route 113 00:08:02,350 --> 00:08:05,600 handler just yet because I feel like that would kind of confuse things. 114 00:08:05,740 --> 00:08:07,740 So I'm going to open up a new file. 115 00:08:07,780 --> 00:08:11,090 I'm not going to say this I just want to use it as a possible example. 116 00:08:11,500 --> 00:08:14,420 Oops I definitely hit the wrong button there. 117 00:08:15,220 --> 00:08:21,340 And we're going to write our sample query right into here just kind of in total isolation so we can 118 00:08:21,340 --> 00:08:23,220 kind of get a better sense of what's going on. 119 00:08:23,500 --> 00:08:30,820 So we're going to say look at our collection of surveys and find one record that matches this given 120 00:08:30,820 --> 00:08:32,850 criteria that we are about to provide. 121 00:08:33,190 --> 00:08:38,260 So the first piece of criteria that we really care about here is making sure that we find a survey that 122 00:08:38,260 --> 00:08:41,520 has an ID of survey ID. 123 00:08:41,880 --> 00:08:42,760 Right that makes sense. 124 00:08:42,760 --> 00:08:47,400 We want to make sure that we have an ID with our survey with the correct ID. 125 00:08:47,440 --> 00:08:53,050 Now the next piece of query logic in here the next kind of filter that we're going to provide to this 126 00:08:53,050 --> 00:08:58,870 query is to make sure that we are also finding a survey that has a recipient with the correct email 127 00:08:58,870 --> 00:08:59,650 property. 128 00:08:59,710 --> 00:09:03,730 And they responded property of false because that's what we really want. 129 00:09:03,730 --> 00:09:08,710 So this next piece of logic right here this next kind of filtering criteria or this next search criteria 130 00:09:08,710 --> 00:09:12,310 that we're going to pass in is going to be a little bit more complex. 131 00:09:12,400 --> 00:09:21,460 We're going to say find a survey that not only has the correct survey ID but also look into its recipients 132 00:09:21,610 --> 00:09:30,340 sub document collection inside of that sub document collection find an element that matches some given 133 00:09:30,340 --> 00:09:31,370 criteria. 134 00:09:31,780 --> 00:09:39,760 So we're going to say dollar sign L-M match and then we're going to pass it the kind of sub criteria 135 00:09:39,760 --> 00:09:44,890 that we want to do as a search here and we'll talk about this Elham match thing is in just a second. 136 00:09:44,890 --> 00:09:50,740 So we're going to say one of the recipients inside the recipient of document collection should have 137 00:09:50,740 --> 00:09:57,550 an email of email and responded property of false like so. 138 00:09:57,940 --> 00:10:02,380 So this is pretty much the actual query that we're going to end up writing right here. 139 00:10:02,380 --> 00:10:04,130 Let's walk through the entire thing. 140 00:10:04,210 --> 00:10:13,300 We say go through the entire survey collection and find exactly one record that has an I.D. of survey 141 00:10:13,300 --> 00:10:13,870 I.D.. 142 00:10:14,110 --> 00:10:16,990 So hopefully this first part right here this is you know pretty straightforward. 143 00:10:16,990 --> 00:10:18,350 Not too bad. 144 00:10:18,400 --> 00:10:21,310 The second part right here is where things get really interesting. 145 00:10:21,670 --> 00:10:28,180 So this little block of code right here says for every survey in that service collection look through 146 00:10:28,210 --> 00:10:35,650 its recipient's property the recipient's property should be a sub document collection that has an array 147 00:10:35,650 --> 00:10:36,980 of records. 148 00:10:37,060 --> 00:10:45,060 So go through all those different elements go through all the different sub documents and find one element 149 00:10:45,360 --> 00:10:53,130 that matches this given criteria right here specifically a recipient who has an e-mail of e-mail and 150 00:10:53,130 --> 00:10:58,110 you know presumably we're going to define the e-mail ahead of time appear like a dot com or something 151 00:10:58,110 --> 00:10:59,320 like that. 152 00:10:59,670 --> 00:11:04,830 And then also make sure that that recipient has a responded property of false. 153 00:11:04,830 --> 00:11:09,290 So this query right here would pretty much execute what we just walk through over here. 154 00:11:09,300 --> 00:11:13,650 We would say make sure that it has the correct I.D. make sure it has the correct e-mail and make sure 155 00:11:13,650 --> 00:11:16,110 it has the respondent property are false. 156 00:11:16,260 --> 00:11:19,500 And if the survey doesn't have all three of those criteria true. 157 00:11:19,710 --> 00:11:22,680 Well then we must not have a record that fits the bill here. 158 00:11:22,680 --> 00:11:28,350 Go and find some other record and discontinue searching through the collection until you find one that 159 00:11:28,470 --> 00:11:30,240 satisfies all these requirements. 160 00:11:30,240 --> 00:11:34,850 And of course you and I know that we don't have any other record that satisfies those requirements. 161 00:11:35,390 --> 00:11:35,750 OK. 162 00:11:35,760 --> 00:11:40,290 So I think that maybe you've got a reasonable sense of what this court is going to do at this point. 163 00:11:40,290 --> 00:11:45,570 So we're saying Go and find one record that matches all of the search criteria. 164 00:11:45,570 --> 00:11:49,830 Now we're going to throw kind of an extra level in here at this point we've only been talking about 165 00:11:50,070 --> 00:11:55,800 kind of finding this one record and then presumably we would be turning it back over to our express 166 00:11:55,800 --> 00:11:59,270 server updating it and then send you back on to. 167 00:11:59,750 --> 00:12:07,050 But I would suggest maybe we can not only find the exactly correct survey with the exactly correct recipient 168 00:12:07,380 --> 00:12:13,920 but we can also update that same record at the exact same time that is if it is found inside of our 169 00:12:13,920 --> 00:12:15,250 survey collection. 170 00:12:15,570 --> 00:12:21,360 So rather than saying find one record inside of our surveys collection we're going to use a different 171 00:12:21,360 --> 00:12:27,610 method that is included on our mongoose model class called update 1. 172 00:12:27,810 --> 00:12:34,140 So this update one function right here says Go and find a record with this given search criteria. 173 00:12:34,320 --> 00:12:36,210 After that record is found. 174 00:12:36,300 --> 00:12:42,510 Take the second object that we are going to provide as an argument to this thing and update the record 175 00:12:42,510 --> 00:12:46,410 that was just found with this object right here. 176 00:12:46,470 --> 00:12:47,910 And so that's really what we want to do right. 177 00:12:47,920 --> 00:12:49,160 And one big go. 178 00:12:49,260 --> 00:12:53,310 We want to find the correct survey and then immediately update it. 179 00:12:53,310 --> 00:12:57,480 And we want this update to be entirely done inside of the Mongo world. 180 00:12:57,480 --> 00:13:01,310 We do not really want to pull this survey over to our express server at all. 181 00:13:01,320 --> 00:13:05,280 We don't care about this survey or inside of our handler right now. 182 00:13:05,280 --> 00:13:05,770 Right. 183 00:13:05,790 --> 00:13:09,680 If we go back over a survey routes we don't care about getting a handle on that survey. 184 00:13:09,690 --> 00:13:14,150 We just care about making sure that we update the survey and nothing else. 185 00:13:15,710 --> 00:13:21,440 So if we add in the second argument here and passing an object that describes how we want to update 186 00:13:21,440 --> 00:13:26,660 the record the entire update will be taken care of inside of the Mongo database. 187 00:13:26,660 --> 00:13:31,330 And we never have to actually load any of this data back over to express. 188 00:13:32,120 --> 00:13:34,760 So at this point I think we've covered a pretty good number of topics. 189 00:13:34,760 --> 00:13:39,680 Let's take a quick break and then we'll continue in the next section and talk about exactly what data 190 00:13:39,680 --> 00:13:44,530 we're going to put inside the second object to describe how that survey should be updated. 191 00:13:44,540 --> 00:13:47,060 So let's take a quick break and I'll see you in just a minute.