1
00:00:00,670 --> 00:00:06,330
In the last section we finished up our processing pipeline so we map over the list of all the records

2
00:00:06,330 --> 00:00:09,010
or all the events in the rec body array.

3
00:00:09,030 --> 00:00:15,030
We do some processing and then we eventually spit out a new array and assigned to the variable events.

4
00:00:15,030 --> 00:00:21,510
So now this event's array right here is a array of objects each of which look a little something like

5
00:00:21,510 --> 00:00:22,080
this.

6
00:00:22,080 --> 00:00:27,150
So there are objects that have a survey ID an email in a choice.

7
00:00:27,150 --> 00:00:32,670
The next step inside of our request handler is going to be to make sure that we look up every given

8
00:00:32,670 --> 00:00:39,850
survey by its survey ID we'd check to see if the given email has already voted on the survey before.

9
00:00:40,110 --> 00:00:44,670
And if it has not we're going to update the survey with the given choice.

10
00:00:44,670 --> 00:00:45,670
So either yes.

11
00:00:45,690 --> 00:00:50,740
They want to give some positive feedback or no they want to answer in the negative as a no response

12
00:00:51,350 --> 00:00:52,010
as a reminder.

13
00:00:52,020 --> 00:00:56,400
These surveys themselves have both a yes and a no property.

14
00:00:56,460 --> 00:01:01,770
So if we open up our models directory and find our survey data J.S. file inside of here you'll recall

15
00:01:01,770 --> 00:01:05,040
that yeah the surveys have a yes and a no property.

16
00:01:05,220 --> 00:01:08,180
So essentially we want to look at this choice thing right here.

17
00:01:08,340 --> 00:01:14,730
If it says yes increment the number of yes votes if it says no increment the number of no votes.

18
00:01:14,730 --> 00:01:19,890
So we're very clearly starting to go into the realm of mongoose Imago at this point because we're saying

19
00:01:19,890 --> 00:01:25,860
that we want to look through our collection of surveys and find a survey with the given I.D. and then

20
00:01:25,860 --> 00:01:30,420
we want to go through our sub document collection of recipients and find a recipient with the given

21
00:01:30,440 --> 00:01:34,310
e-mail so we can check to see if this person has voted before.

22
00:01:34,350 --> 00:01:39,630
Now before we just dive right in and start writing out some type of query with Mongoose and Mongo to

23
00:01:39,630 --> 00:01:41,030
make all this stuff happen.

24
00:01:41,310 --> 00:01:47,220
I want to show you a little bit of code that I took the liberty of writing myself that I would call

25
00:01:47,250 --> 00:01:50,300
a very bad approach to this problem.

26
00:01:50,310 --> 00:01:56,070
So again I wrote out some code to look through the surveys collection find the given survey checked

27
00:01:56,100 --> 00:02:00,930
to see if the e-mail has been used before increment the choice property on the survey and then save

28
00:02:00,930 --> 00:02:02,550
it back to the database.

29
00:02:02,550 --> 00:02:07,800
Now the reason I wrote this code out already is I did it in a very poor fashion I do in a way that I

30
00:02:07,800 --> 00:02:10,790
would highly recommend you not write it out yourself.

31
00:02:10,830 --> 00:02:16,490
And so I want to give you an example of how not to write mongoose and Mongo queries.

32
00:02:16,590 --> 00:02:21,030
Obviously I wanted to do all this work up front and write it all out so I can show it to you so that

33
00:02:21,060 --> 00:02:21,410
you don't.

34
00:02:21,410 --> 00:02:25,470
We don't have to write it out together and then have me say oh yeah turns out this is a real horrible

35
00:02:25,470 --> 00:02:26,210
approach.

36
00:02:26,370 --> 00:02:26,600
OK.

37
00:02:26,610 --> 00:02:31,730
So again I just wanted to give you an example of how how not to treat this query that we need to write.

38
00:02:32,030 --> 00:02:32,300
OK.

39
00:02:32,310 --> 00:02:33,800
So we'll look at the bad code now.

40
00:02:33,960 --> 00:02:37,500
The bad example the way not to do this.

41
00:02:37,620 --> 00:02:38,820
So here's the code right here.

42
00:02:38,970 --> 00:02:41,040
Let's just kind of very briefly walk through it.

43
00:02:41,040 --> 00:02:42,930
We don't really have to understand each statement.

44
00:02:42,930 --> 00:02:46,860
I just want you to get kind of a general gist gist of what's going on.

45
00:02:46,920 --> 00:02:47,660
OK.

46
00:02:48,030 --> 00:02:53,280
So at the very top we are iterating over the list of all the different events that we have now processed.

47
00:02:53,280 --> 00:02:58,240
We've said that every event has a survey ID and email and a choice.

48
00:02:58,260 --> 00:03:03,980
So the first thing we do inside iffier is we go through our survey collection and find a survey with

49
00:03:03,980 --> 00:03:05,300
a given I.D..

50
00:03:05,520 --> 00:03:10,980
Now just to kind of tabulate the work that we're doing with our Mongo database as we walk to this code

51
00:03:11,040 --> 00:03:15,600
I want to point out to you that when we run this statement right here this is going to reach over to

52
00:03:15,600 --> 00:03:16,990
our Mago database.

53
00:03:17,040 --> 00:03:21,190
It's going to do a search for the given survey and then return it over to our node.

54
00:03:21,210 --> 00:03:28,630
J.S. runtime times like our running server we are pulling data from Mongo over to our express server.

55
00:03:29,370 --> 00:03:36,270
Next after we load up the given survey we iterate through the list of recipients until we find a recipient

56
00:03:36,630 --> 00:03:41,190
who has the equivalent email and has not yet responded to the survey.

57
00:03:41,190 --> 00:03:47,100
If we find ever Scipion like this if we find a recipient with a given email who has not responded we

58
00:03:47,100 --> 00:03:49,620
assign it to the responder variable.

59
00:03:49,710 --> 00:03:55,880
And so now responder can either be a recipient model or it can be undefined or not.

60
00:03:55,950 --> 00:04:02,160
Essentially either we correctly found this record or no we didn't find anyone who matches this or anyone

61
00:04:02,160 --> 00:04:06,350
who is a kind of valid recipient for the purposes of voting on our survey.

62
00:04:06,360 --> 00:04:12,240
So if we did not find a valid recipient then we just returned early and we say a Chances are this person

63
00:04:12,240 --> 00:04:16,320
has already voted on the survey before because remember we want to make sure that every person only

64
00:04:16,320 --> 00:04:17,540
votes once.

65
00:04:17,940 --> 00:04:23,670
However if we did find a valid recipient then we assume that this person has never responded before.

66
00:04:23,850 --> 00:04:26,840
So we update their responded flag to true.

67
00:04:27,120 --> 00:04:31,450
We then increment the number of kind of yes or no votes on the survey.

68
00:04:31,740 --> 00:04:35,990
We marked the last responded date as right now essentially.

69
00:04:36,390 --> 00:04:38,850
And then we saved the survey back to the database.

70
00:04:39,210 --> 00:04:39,460
OK.

71
00:04:39,480 --> 00:04:44,280
So now let's kind of you know hopefully that flow right there makes sense like this logic is very methodical

72
00:04:44,580 --> 00:04:46,080
we go and find the correct survey.

73
00:04:46,110 --> 00:04:49,680
We update the survey and we save everything back to the database.

74
00:04:49,680 --> 00:04:56,300
So let me now tell you why this is a bad approach that we have taken again and this very top line up

75
00:04:56,310 --> 00:05:04,400
here makes a query on our database it finds appropriate survey and then returns the survey in the entire

76
00:05:04,460 --> 00:05:09,320
sub document collection of recipients back to our express server.

77
00:05:09,380 --> 00:05:11,380
And that part is the part that's bad.

78
00:05:11,540 --> 00:05:15,550
That's the part that we want to avoid when ever we fetch the survey right here.

79
00:05:15,550 --> 00:05:20,820
We are not only getting the survey model but all the survey record the survey instance.

80
00:05:20,930 --> 00:05:27,140
But we are also getting the entire sub document collection of all these different recipients and in

81
00:05:27,140 --> 00:05:34,340
total there might be thousands hundreds tens of thousands of different assts recipients associated with

82
00:05:34,340 --> 00:05:35,750
each survey.

83
00:05:35,750 --> 00:05:42,020
So even though we only care about one very particular recipient we are possibly shuttling back and forth

84
00:05:42,080 --> 00:05:49,040
this gigantic enormous list of recipients way more data than we ever really need to care about.

85
00:05:49,670 --> 00:05:55,600
After we get this list of recipients over to our express server we are then doing a very manual lookup

86
00:05:55,640 --> 00:06:00,590
through that recipient survey to find the given recipient who was kind of like the valid person and

87
00:06:00,590 --> 00:06:03,840
the person who has to give an email and has not yet responded.

88
00:06:03,950 --> 00:06:08,660
And so we are walking through that list of recipients one by one checking every single one of these

89
00:06:08,660 --> 00:06:14,760
possibly hundreds or thousands or tens of thousands of records to see if we have found the correct recipient.

90
00:06:14,930 --> 00:06:22,070
When we do find the correct recipient We then update just responded property and then we save the survey

91
00:06:22,070 --> 00:06:23,470
back to the database.

92
00:06:23,480 --> 00:06:31,520
Now when we call save like this this sends back not only the survey but the entire list of recipients

93
00:06:31,580 --> 00:06:32,260
as well.

94
00:06:32,270 --> 00:06:36,720
So we're sending back the entire list of recipients every single last one of them.

95
00:06:36,860 --> 00:06:42,920
Again hundreds thousands tens of thousands of recipients are being sent back over to the Mago database

96
00:06:43,280 --> 00:06:47,390
even though we only cared about one very specific recipient.

97
00:06:47,420 --> 00:06:51,270
And we only cared about updating that one very specific property.

98
00:06:51,650 --> 00:06:54,590
So the bad approach or the reason this is all going bad.

99
00:06:54,590 --> 00:06:57,610
Yeah you know I'm saying like oh yeah we're sending all these records back and forth.

100
00:06:57,710 --> 00:07:02,450
Well clearly that's not the best approach here we are shuttling back and forth a tremendous amount of

101
00:07:02,450 --> 00:07:08,240
data between our database and our express server that we are only touching or we only care about some

102
00:07:08,330 --> 00:07:11,870
very tall tiny small slice of all that data.

103
00:07:11,870 --> 00:07:15,560
So I'm going to suggest that the approach that we just took right here or the approach that I kind of

104
00:07:15,560 --> 00:07:21,380
wrote out here would have been a very poor way of handling this query in which we want to assign the

105
00:07:21,440 --> 00:07:23,610
choice to the given survey.

106
00:07:24,900 --> 00:07:28,710
So hopefully this makes a little bit of sense why we might not take this approach.

107
00:07:28,710 --> 00:07:33,790
We always want to minimize the amount of data that we are attempting to pull out of our database.

108
00:07:33,990 --> 00:07:40,050
In doing so we're going to try to make sure that we always execute as much search logic and as much

109
00:07:40,170 --> 00:07:47,220
update logic inside of Mongo rather than pulling this data over to our server updating it searching

110
00:07:47,220 --> 00:07:49,470
through it and then saving it back over to lango.

111
00:07:49,470 --> 00:07:51,420
So in other words what I'm suggesting.

112
00:07:51,450 --> 00:07:57,630
Well I think we should do is I think that we should find some way rather than pulling out just the given

113
00:07:57,630 --> 00:07:59,190
survey from the database.

114
00:07:59,190 --> 00:08:06,210
I think that we should find some way of finding the appropriate survey and only one very particular

115
00:08:06,210 --> 00:08:10,800
recipient that we actually care about inside of the recipient of document collection.

116
00:08:10,800 --> 00:08:14,480
So I don't want to pull out over the entire subdominant collection.

117
00:08:14,520 --> 00:08:20,250
I want to only be concerned with this one very singular record that we actually care about the given

118
00:08:20,250 --> 00:08:25,640
recipient the recipient with the matching email to the one that we just got inside the event.

119
00:08:25,680 --> 00:08:27,420
So hopefully this is making a little bit of sense here.

120
00:08:27,420 --> 00:08:33,930
Again we want to execute as much logic and as much queries stuff on the Mungo's side rather than trying

121
00:08:33,930 --> 00:08:39,570
to write out all this manual search logic on our side of the application or on the Express side.

122
00:08:39,570 --> 00:08:43,970
So with this kind of cautionary tale out of the way let's take a break.

123
00:08:43,980 --> 00:08:48,240
We'll continue with the next section and we're going to talk about how we are going to write a query

124
00:08:48,540 --> 00:08:54,450
that puts as much burden of all this kind of search feature onto Mongo as possible because doing all

125
00:08:54,450 --> 00:08:57,450
these queries inside of Monga is very fast and very quick.

126
00:08:57,540 --> 00:09:01,180
It's much slower to execute on our Express side of things.

127
00:09:01,190 --> 00:09:02,270
So let's take a quick break.

128
00:09:02,280 --> 00:09:06,420
We'll come back in the next section and figure out exactly how we're going to write this query.

129
00:09:06,420 --> 00:09:08,390
So I'll see you in just a minute.