1
00:00:02,150 --> 00:00:07,050
So let's play around with the write concern and for that I'll go back to my persons,

2
00:00:07,280 --> 00:00:12,050
there we already have a couple of persons in the database of course and

3
00:00:12,110 --> 00:00:16,070
all these writes succeeded and they normally will of course.

4
00:00:16,100 --> 00:00:22,190
Now let's insert a new person with insert one and the write concern can also be set on all other write

5
00:00:22,190 --> 00:00:32,360
operations like insert many, I will use insert one here with a name of Chrissy, age 41

6
00:00:32,720 --> 00:00:38,010
and now I specify a second argument again where we previously set orders,

7
00:00:38,150 --> 00:00:40,520
I will now set my write concern.

8
00:00:41,150 --> 00:00:43,500
I do this by setting the write concern,

9
00:00:43,640 --> 00:00:44,510
named like this,

10
00:00:44,510 --> 00:00:45,600
the casing is important,

11
00:00:45,620 --> 00:00:50,570
so the write concern key, I set it to a value which again is a document which has the shape you saw on

12
00:00:50,570 --> 00:00:51,680
the slides.

13
00:00:51,700 --> 00:00:53,080
W 1 is the default,

14
00:00:53,090 --> 00:00:57,700
it simply means I need to be sure that the server acknowledge this,

15
00:00:57,740 --> 00:01:02,950
you can set this to 0. If you do this, you get back acknowledged false

16
00:01:02,960 --> 00:01:06,430
but if I find everything, you see that Chrissy was inserted.

17
00:01:06,740 --> 00:01:10,010
So you get back a different result, also without an objectID

18
00:01:10,040 --> 00:01:15,860
because it can't give you one, the server hasn't really registered this write yet, you just sent the request

19
00:01:15,860 --> 00:01:16,990
and you immediately return,

20
00:01:17,000 --> 00:01:20,000
you don't wait for a response of this request, so to say.

21
00:01:20,000 --> 00:01:26,360
So the storage engine had no chance to store it in memory and generate that objectId and therefore, you get

22
00:01:26,360 --> 00:01:32,590
back acknowledged false because you sent the request, you don't even know if it reached the server.

23
00:01:32,600 --> 00:01:38,420
This is of course super fast because you don't have to wait for any response here, for any ID generation

24
00:01:38,930 --> 00:01:44,270
but obviously, it tells you nothing about whether this succeeded or not. Could still be a valid option

25
00:01:44,450 --> 00:01:48,890
for data where it's ok for you, if some data does not end up in a database,

26
00:01:48,890 --> 00:01:54,620
so if you log some value every second about an application and you don't care if a couple of seconds

27
00:01:54,620 --> 00:01:56,510
get lost, you could do that.

28
00:01:56,510 --> 00:01:59,390
So that is w 0, the default with

29
00:02:03,030 --> 00:02:11,080
Alex who is 36, the default is w 1 of course, this gives you the output you saw before, acknowledge

30
00:02:11,080 --> 00:02:11,540
true

31
00:02:11,620 --> 00:02:16,170
and the inserted ID.

32
00:02:16,250 --> 00:02:25,110
Now let's go for Michael and let's play around with the journal,

33
00:02:25,450 --> 00:02:28,120
the journal can be set to true,

34
00:02:28,150 --> 00:02:30,360
the default is undefined or false,

35
00:02:30,360 --> 00:02:34,340
so if I set it to false, I have the same result as before.

36
00:02:34,390 --> 00:02:44,660
Now if I change it to McKayla and we set the journal to true now, the output for us does not change and

37
00:02:44,720 --> 00:02:45,020
.

38
00:02:45,020 --> 00:02:48,150
it also was super fast here because everything runs locally

39
00:02:48,300 --> 00:02:54,750
and it's not like the journaling will take four hours but it will have been a little bit slower because

40
00:02:54,750 --> 00:03:01,950
the entry will have been added to the journal and we waited for that journal editing to finish here.

41
00:03:02,160 --> 00:03:07,410
So here, we have higher security because we can also be sure that it ended up in this to do list of the

42
00:03:07,410 --> 00:03:12,530
storage engine which will eventually lead to the writes happen to database files.

43
00:03:12,540 --> 00:03:14,340
So now we got this,

44
00:03:14,340 --> 00:03:27,630
now let me add another person, Aliya 22 and let me also add a third option, w timeout. If I add this like this,

45
00:03:27,700 --> 00:03:29,530
it succeeded. Now

46
00:03:29,560 --> 00:03:31,930
if I repeat it with a very small value,

47
00:03:31,960 --> 00:03:37,960
it also succeeded because this is super fast here but it is an option which you can set in case

48
00:03:37,960 --> 00:03:44,620
you get shaky, a shaky connection or speed really matters and your connection is generally good but you

49
00:03:44,620 --> 00:03:46,630
can't rule out that once in a year,

50
00:03:46,630 --> 00:03:53,680
it's kind of shaky and you would then rather have that write fail and you recognize this in your client

51
00:03:53,680 --> 00:03:56,940
application of course because you'll get back an error here too.

52
00:03:57,100 --> 00:04:03,250
So you'll have that write fail and therefore you can try again later but you don't wait unnecessarily

53
00:04:03,250 --> 00:04:03,870
long.

54
00:04:03,970 --> 00:04:06,940
So this can absolutely be something you are fine with.