We're doing some validation on the incoming request.
So now we need to start to think about the body of this request handler.
Remember the entire goal of this request handler is to take in some information about a ticket that
the user is trying to purchase and then create an order record and save in order to our Mongo DB database.
Any time we'd talk about saving information to our database that always means so we need to create a
mongoose model.
Right now our orders project does not have any models tied to it.
So before we can continue with building out this request HANDLER We have to create a mongoose model
to describe what in order is.
So in this video we're going to tackle a bit more about exactly what an order is and how we're going
to model it inside of our database.
All right.
So back in this diagram over here we're talking about the order service.
We said that this thing was going to have a collection of orders in every order would have a user I.D.
status expires that and it would also somehow reference a ticket as well so when we talk about saving
orders to the database.
Well inevitably we also need to think about how we're going to save tickets to the database and most
importantly how we're going to relate these two things together.
And that's what I really want to discuss in this video.
How are we going to somehow relate an order to a ticket so we need to associate these two things together
somehow.
We're going to have inside of our database presumably in some fashion a collection of different tickets
that are available to be purchased.
And once the user tries to create an order we need to somehow mark that ticket as being reserved or
associated with a very particular order so we start to discuss associating records together with Mongo
DB.
There are two primary strategies that we can use so we can take a look at the two primary strategies
we can use to associate in order with a ticket So option number one or strategy number one is referred
to as embedding with him and Bettman strategy we might have an order like this right here.
So this would be an order document.
We would have the user I.D. status expires out and then to somehow associate an order with a ticket.
We could embed the information about that ticket directly inside the order itself.
So in other words you would have a ticket property and that would be a plane object with some I.D. some
price for the ticket and some title as well.
This would make it really easy to figure out what orders are concerned with what tickets.
So we can very easily look up and order and say ah right here on the ticket property this is the ticket
that the user is attempting to purchase.
So this is one way that we can associate orders and tickets together.
But there are some definite big downsides to it for our particular application.
So here's ups or bet downside at number one whenever a user tries to make a request to create an order
we need to make sure that that ticket that they're trying to order is not already reserved.
So if we start to embed these tickets inside of each order making sure that a ticket is not already
reserved is going to start to get just a little bit challenging to query as we're going to essentially
have to take a look at all the different orders that have been created over time.
Take a look at the tickets embedded inside of each one.
Take a look at the idea and make sure that I.D. is not equal to the idea that is inside of this incoming
request if an idea is already listed inside of an existing order or if a ticket is already list inside
of an existing order.
That means the ticket would be in use.
So downside number 1 to option number one is that query to make sure that ticket is not in use just
a little bit challenging but there is a way bigger downside something that makes this embedding approach
just about impossible to implement for our particular application.
Remember we're going to have our ticket service and that's going to eventually emit events like ticket
created and ticket updated.
These events will be received by the order service.
Now every ticket that gets created is not going to be immediately assigned to an order.
There will be some point time where someone creates a ticket to sell and then it's just listed on our
website waiting for someone to purchase it.
So we need a way to essentially have tickets represented or an inside of our order service without actually
associating them directly with an order.
In other words there has to be a separate pool a pool of records that say here's a list of all the tickets
that no one has tried to purchase yet so this option number one strategy where we embed tickets inside
of an order document really just not feasible because we really cannot have some kind of standby pool
of tickets that are waiting to be purchased.
So we're not going to be making use of embedding.
Instead we're going to take a look at a different strategy.
So this is kind of general strategy.
Number two we're associating records with Mongo deeds and mongoose.
We're going to use a feature inside a mongoose called the ref or population feature so the ref or a
population feature however you want to refer to it.
We're going to have a collection of documents about orders and a collection of documents about tickets.
So a orders collection and a ticket collection then inside of every order they can optionally have a
reference to a ticket.
So we will have some ticket property and this will essentially somehow be a reference over to a ticket
inside of our tickets collection so two separate collections.
This will make it really easy for us to query all the different tickets and figure out if a given ticket
is in use or not.
We can also very easily find all the different tickets that are still awaiting to be purchased and list
them out separately on the react side of our application as well.
So this is the strategy we're going to use we're going to use the ref or population feature.
Now the reason I'm making such a real big deal around this stuff you know when we looked at this diagram
over here it might have already been kind of obvious to you.
Oh yeah okay.
Or collection of orders collection tickets.
And so this video might seem a little bit unnecessary.
The big reason I'm giving you this explanation is that later on this relationship that we're setting
up for some features we're going to build in a little bit is actually going to become really really
really important.
And on top of that setting up this relationship with Mongoose where we have some ticket property on
the order document referring to a ticket there's actually a little trick or two that you need to be
aware of around that as well.
So that's why we did this kind of extra video just to kind of clarify the relationship between the stuff.
So at the end the day the strategy that we're going to be forward with we're going to have a collection
of orders a collection of tickets we're going to relate the two together or associate the two together
using this ref or population feature.
I'll show you how this feature works if you're not familiar with it.
Otherwise you can always take a look at the Mongoose documentation and understand a little bit more
about how it works.
Quick pause right here.
When we come back the next video we're gonna start to write out an implementation or our order document
and then the ticket document right after that so quick possible see you in just a minute.