So let's play around with the write concern and for that I'll go back to my persons,
there we already have a couple of persons in the database of course and
all these writes succeeded and they normally will of course.
Now let's insert a new person with insert one and the write concern can also be set on all other write
operations like insert many, I will use insert one here with a name of Chrissy, age 41
and now I specify a second argument again where we previously set orders,
I will now set my write concern.
I do this by setting the write concern,
named like this,
the casing is important,
so the write concern key, I set it to a value which again is a document which has the shape you saw on
the slides.
W 1 is the default,
it simply means I need to be sure that the server acknowledge this,
you can set this to 0. If you do this, you get back acknowledged false
but if I find everything, you see that Chrissy was inserted.
So you get back a different result, also without an objectID
because it can't give you one, the server hasn't really registered this write yet, you just sent the request
and you immediately return,
you don't wait for a response of this request, so to say.
So the storage engine had no chance to store it in memory and generate that objectId and therefore, you get
back acknowledged false because you sent the request, you don't even know if it reached the server.
This is of course super fast because you don't have to wait for any response here, for any ID generation
but obviously, it tells you nothing about whether this succeeded or not. Could still be a valid option
for data where it's ok for you, if some data does not end up in a database,
so if you log some value every second about an application and you don't care if a couple of seconds
get lost, you could do that.
So that is w 0, the default with
Alex who is 36, the default is w 1 of course, this gives you the output you saw before, acknowledge
true
and the inserted ID.
Now let's go for Michael and let's play around with the journal,
the journal can be set to true,
the default is undefined or false,
so if I set it to false, I have the same result as before.
Now if I change it to McKayla and we set the journal to true now, the output for us does not change and
.
it also was super fast here because everything runs locally
and it's not like the journaling will take four hours but it will have been a little bit slower because
the entry will have been added to the journal and we waited for that journal editing to finish here.
So here, we have higher security because we can also be sure that it ended up in this to do list of the
storage engine which will eventually lead to the writes happen to database files.
So now we got this,
now let me add another person, Aliya 22 and let me also add a third option, w timeout. If I add this like this,
it succeeded. Now
if I repeat it with a very small value,
it also succeeded because this is super fast here but it is an option which you can set in case
you get shaky, a shaky connection or speed really matters and your connection is generally good but you
can't rule out that once in a year,
it's kind of shaky and you would then rather have that write fail and you recognize this in your client
application of course because you'll get back an error here too.
So you'll have that write fail and therefore you can try again later but you don't wait unnecessarily
long.
So this can absolutely be something you are fine with.