In the last section we finished up our processing pipeline so we map over the list of all the records
or all the events in the rec body array.
We do some processing and then we eventually spit out a new array and assigned to the variable events.
So now this event's array right here is a array of objects each of which look a little something like
this.
So there are objects that have a survey ID an email in a choice.
The next step inside of our request handler is going to be to make sure that we look up every given
survey by its survey ID we'd check to see if the given email has already voted on the survey before.
And if it has not we're going to update the survey with the given choice.
So either yes.
They want to give some positive feedback or no they want to answer in the negative as a no response
as a reminder.
These surveys themselves have both a yes and a no property.
So if we open up our models directory and find our survey data J.S. file inside of here you'll recall
that yeah the surveys have a yes and a no property.
So essentially we want to look at this choice thing right here.
If it says yes increment the number of yes votes if it says no increment the number of no votes.
So we're very clearly starting to go into the realm of mongoose Imago at this point because we're saying
that we want to look through our collection of surveys and find a survey with the given I.D. and then
we want to go through our sub document collection of recipients and find a recipient with the given
e-mail so we can check to see if this person has voted before.
Now before we just dive right in and start writing out some type of query with Mongoose and Mongo to
make all this stuff happen.
I want to show you a little bit of code that I took the liberty of writing myself that I would call
a very bad approach to this problem.
So again I wrote out some code to look through the surveys collection find the given survey checked
to see if the e-mail has been used before increment the choice property on the survey and then save
it back to the database.
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
would highly recommend you not write it out yourself.
And so I want to give you an example of how not to write mongoose and Mongo queries.
Obviously I wanted to do all this work up front and write it all out so I can show it to you so that
you don't.
We don't have to write it out together and then have me say oh yeah turns out this is a real horrible
approach.
OK.
So again I just wanted to give you an example of how how not to treat this query that we need to write.
OK.
So we'll look at the bad code now.
The bad example the way not to do this.
So here's the code right here.
Let's just kind of very briefly walk through it.
We don't really have to understand each statement.
I just want you to get kind of a general gist gist of what's going on.
OK.
So at the very top we are iterating over the list of all the different events that we have now processed.
We've said that every event has a survey ID and email and a choice.
So the first thing we do inside iffier is we go through our survey collection and find a survey with
a given I.D..
Now just to kind of tabulate the work that we're doing with our Mongo database as we walk to this code
I want to point out to you that when we run this statement right here this is going to reach over to
our Mago database.
It's going to do a search for the given survey and then return it over to our node.
J.S. runtime times like our running server we are pulling data from Mongo over to our express server.
Next after we load up the given survey we iterate through the list of recipients until we find a recipient
who has the equivalent email and has not yet responded to the survey.
If we find ever Scipion like this if we find a recipient with a given email who has not responded we
assign it to the responder variable.
And so now responder can either be a recipient model or it can be undefined or not.
Essentially either we correctly found this record or no we didn't find anyone who matches this or anyone
who is a kind of valid recipient for the purposes of voting on our survey.
So if we did not find a valid recipient then we just returned early and we say a Chances are this person
has already voted on the survey before because remember we want to make sure that every person only
votes once.
However if we did find a valid recipient then we assume that this person has never responded before.
So we update their responded flag to true.
We then increment the number of kind of yes or no votes on the survey.
We marked the last responded date as right now essentially.
And then we saved the survey back to the database.
OK.
So now let's kind of you know hopefully that flow right there makes sense like this logic is very methodical
we go and find the correct survey.
We update the survey and we save everything back to the database.
So let me now tell you why this is a bad approach that we have taken again and this very top line up
here makes a query on our database it finds appropriate survey and then returns the survey in the entire
sub document collection of recipients back to our express server.
And that part is the part that's bad.
That's the part that we want to avoid when ever we fetch the survey right here.
We are not only getting the survey model but all the survey record the survey instance.
But we are also getting the entire sub document collection of all these different recipients and in
total there might be thousands hundreds tens of thousands of different assts recipients associated with
each survey.
So even though we only care about one very particular recipient we are possibly shuttling back and forth
this gigantic enormous list of recipients way more data than we ever really need to care about.
After we get this list of recipients over to our express server we are then doing a very manual lookup
through that recipient survey to find the given recipient who was kind of like the valid person and
the person who has to give an email and has not yet responded.
And so we are walking through that list of recipients one by one checking every single one of these
possibly hundreds or thousands or tens of thousands of records to see if we have found the correct recipient.
When we do find the correct recipient We then update just responded property and then we save the survey
back to the database.
Now when we call save like this this sends back not only the survey but the entire list of recipients
as well.
So we're sending back the entire list of recipients every single last one of them.
Again hundreds thousands tens of thousands of recipients are being sent back over to the Mago database
even though we only cared about one very specific recipient.
And we only cared about updating that one very specific property.
So the bad approach or the reason this is all going bad.
Yeah you know I'm saying like oh yeah we're sending all these records back and forth.
Well clearly that's not the best approach here we are shuttling back and forth a tremendous amount of
data between our database and our express server that we are only touching or we only care about some
very tall tiny small slice of all that data.
So I'm going to suggest that the approach that we just took right here or the approach that I kind of
wrote out here would have been a very poor way of handling this query in which we want to assign the
choice to the given survey.
So hopefully this makes a little bit of sense why we might not take this approach.
We always want to minimize the amount of data that we are attempting to pull out of our database.
In doing so we're going to try to make sure that we always execute as much search logic and as much
update logic inside of Mongo rather than pulling this data over to our server updating it searching
through it and then saving it back over to lango.
So in other words what I'm suggesting.
Well I think we should do is I think that we should find some way rather than pulling out just the given
survey from the database.
I think that we should find some way of finding the appropriate survey and only one very particular
recipient that we actually care about inside of the recipient of document collection.
So I don't want to pull out over the entire subdominant collection.
I want to only be concerned with this one very singular record that we actually care about the given
recipient the recipient with the matching email to the one that we just got inside the event.
So hopefully this is making a little bit of sense here.
Again we want to execute as much logic and as much queries stuff on the Mungo's side rather than trying
to write out all this manual search logic on our side of the application or on the Express side.
So with this kind of cautionary tale out of the way let's take a break.
We'll continue with the next section and we're going to talk about how we are going to write a query
that puts as much burden of all this kind of search feature onto Mongo as possible because doing all
these queries inside of Monga is very fast and very quick.
It's much slower to execute on our Express side of things.
So let's take a quick break.
We'll come back in the next section and figure out exactly how we're going to write this query.
So I'll see you in just a minute.