OUR FIRST ON MESSAGE function has been put together but as I mentioned there's a little issue with the
code implementation to take note of how inside of here we are taking the title and the price of the
ticket using it to build a new ticket and just saving that directly.
I want you to really think about what is going to be happening to the Mongo DV record that gets created
to reflect this ticket.
Let me give you a little hint.
All right.
So this diagram right here we have created a ticket inside of our ticket service and we're going to
imagine that when this ticket right here is created we emit an event that is then received by the order
service and the order service wants to receive that information.
Take the title and the price and persisted into its own local tickets collection.
Just think about what would happen when we insert this ticket with the code that we have currently.
So with this code right here without a doubt we would get the exact same title and the same price no
two ways about it.
But remember whenever we insert a record into Mongo DV It gets assigned a random I.D..
And so this thing would be given an idea of well who knows what this randomly generated idea right here
is.
Without a doubt going to be different than the I.D. that was assigned back inside the ticket service.
That means that we now have two records that are supposed to be mirrors or absolute copies of each other.
But we have zero consistent identifier between them.
So if I now ask you to give me the I.D. or the ticket for I.D. ABC from the order service you would
look at your collection of tickets and you'd say you know what.
I have no idea which of these records matches up with ticket ABC from the ticket service so whenever
we are replicating data across services we want to try to make sure that we are using identical or consistent
I.D. between them.
That's gonna make sure that we can identify these unique records between all these different services.
So long story short we want to make sure it inside the order service that this ticket we are creating
has the exact same I.D. of ABC does give me the first thing that we're gonna fix up.
So how are we going to do that.
Well unfortunately as usual just a little bit complicated.
The first thing we need to do is go and adjust our build function.
Right now our build function does not expect to receive an I.D. our data object right here has the I.D.
we get to pull that out.
That's the idea the ticket that was created.
But if we tried to pass that in like so we're gonna get an error because the build function does not
expect to receive an I.D. let's go back over to our ticket model file.
We're going to adjust the build function and make sure that it can receive an I.D. Here's my ticket
model file I'll find my build method.
Here it is right here and remember the argument of Adam is right here must conform to the ticket Adam's
interface to make sure everything lines up.
All we really have to do is add the I.T. property to the ticket address interface.
So at the top of the file of ticket outers I'll say that whenever we try to build a new ticket we must
provide an I.D. and it must be a string so we'll make the air go away.
But unfortunately that's not going to really solve the issue.
So let me tell you why that is.
One more quick diagram.
So you might recall that inside of Mongo DV we store all of our records with an underscore I.D. property
so when we eventually load this information up into our ticket service from Mongo DB.
It still has underscore I.D. It is only when we take this record and turn it into Jason to be transmitted
over an event that that I.D. gets converted into normal I.D. of one two three instead
right now when we receive that I.D. inside of our order service inside that event it shows up as I.D.
of one two three and we would like to make sure that when this record gets saved to our orders database
it uses that same I.D..
Unfortunately whenever we save a record with just I.D. by itself Mongoose ignores that I.D. property
instead Mongoose says oh this thing doesn't have an underscore I.D..
Well then I'm going to give it a randomly generated I.D. and assign it to the underscore I.D. property.
So if we were to take this record right now and save it we would end up inside of our database with
I.D. of one two three title of concerts and then underscore I.D. of some randomly generated I.D. So
all we really have to do here as the final step need to make sure that when we go and create the new
instance of the ticket inside the build method we take that 80 and assign it to the new record as underscore
I.D. to back inside of our ticket schema file.
Here's the model's directory ticket to yes.
Here's our build method rather than just passing through that entire adders object and just allowing
it to assign the idea property we're going to instead assign all these properties one by one and as
we're doing that we're going to rename the underscore I.D. property so I can put in an object and we're
going to assign underscore I.D. from adders dot I.D. then the title from actors that title and the price
from adders dot price like so.
Now the way that I just did this to rename the underscore I.D. property or I.D. to underscore I.D. not
super ideal because now we are relying upon listing out each property in great detail so in other words
if we start to add some different properties to the ticket adders interface we're going to also have
to come down to our build method and make sure we assign these properties through as well.
And so that's just a little bit of technical debt just something to keep in mind.
All right.
So that should be it for massaging this idea around.
Let's take a quick pause right here and continue it in just a minute.