1
00:00:02,210 --> 00:00:09,920
Now the last interesting index option I want to show to you is a time to live index and that's a really

2
00:00:09,920 --> 00:00:15,800
cool kind of index that can be very helpful for a lot of applications where you have self-destroying

3
00:00:15,800 --> 00:00:16,350
data,

4
00:00:16,490 --> 00:00:22,490
let's say sessions of users where you want to clear their data after some duration or anything like

5
00:00:22,490 --> 00:00:23,470
that.

6
00:00:23,870 --> 00:00:32,200
Let's create a new sessions collection here, you can of course come up with any example you want and

7
00:00:32,380 --> 00:00:43,010
in there, I'll insert one document and that one document will receive some data

8
00:00:45,030 --> 00:00:46,740
which is some random text

9
00:00:46,890 --> 00:00:53,240
and more importantly, it will get a createdAt key and you can name this however you want, doesn't have to

10
00:00:53,240 --> 00:00:56,780
be named createdAt. Now

11
00:00:57,050 --> 00:01:03,550
this will receive a new date and it will receive new date like this which will just be the current timestamp

12
00:01:03,620 --> 00:01:04,850
or the current date,

13
00:01:04,850 --> 00:01:13,370
so if I look into sessions with find pretty, well then I see this ISO date was created by mongodb and

14
00:01:13,380 --> 00:01:16,350
this is the current date and time.

15
00:01:16,420 --> 00:01:20,260
Now let me add a time to live index here, for that,

16
00:01:20,260 --> 00:01:23,630
I'll go to my sessions and create an index

17
00:01:23,680 --> 00:01:27,390
and now I will create that index on the createdAt field.

18
00:01:27,430 --> 00:01:33,220
Now first of all, you could of course create a normal ascending index here too and you can order dates

19
00:01:33,250 --> 00:01:41,220
just like you can text and numbers but now I'll get rid of this because I want to add this index a bit differently.

20
00:01:41,880 --> 00:01:46,140
Instead of adding it as I did before in ascending order,

21
00:01:46,140 --> 00:01:51,060
I was still add it like this but I will add an additional argument here to configure this index and

22
00:01:51,060 --> 00:01:55,690
there, I will add the expire after seconds field.

23
00:01:56,090 --> 00:02:03,910
This is a special feature mongodb offers and that only works on date indexes or on date fields, on other

24
00:02:03,910 --> 00:02:05,170
fields it will just be ignored,

25
00:02:05,170 --> 00:02:07,200
you could add it but it will be ignored

26
00:02:07,390 --> 00:02:12,430
and there I could say every element should be removed after 10 seconds.

27
00:02:12,430 --> 00:02:18,610
Now if I hit enter here and I look into my collection, you'll see this value is still there because it

28
00:02:18,610 --> 00:02:23,960
was there before the index was added and the index does not delete elements in hindsight

29
00:02:24,430 --> 00:02:31,700
but if I insert a new element here, you see it's now in the database

30
00:02:31,770 --> 00:02:35,460
but let's now wait for 10 seconds because that is the duration

31
00:02:35,460 --> 00:02:40,620
I did specify and thereafter you see,

32
00:02:40,710 --> 00:02:42,780
actually both were deleted.

33
00:02:43,080 --> 00:02:44,970
The reason for that is

34
00:02:45,120 --> 00:02:49,880
adding a new element basically triggered mongodb to now re-evaluate the entire collection,

35
00:02:49,920 --> 00:02:57,690
so also the already existing documents and see whether this field which is indexed fulfills this criteria

36
00:02:57,870 --> 00:02:59,750
of only being valid for 10 seconds

37
00:02:59,970 --> 00:03:02,900
and therefore then it also reconsidered the existing documents,

38
00:03:02,910 --> 00:03:04,640
it just doesn't do that right

39
00:03:04,650 --> 00:03:08,930
when you add the index but it does do it whenever you add a new element.

40
00:03:09,360 --> 00:03:14,310
So this can be very useful because it allows you to maintain a collection of documents which destroy

41
00:03:14,310 --> 00:03:18,850
themselves after a certain time span and for a lot of applications,

42
00:03:18,900 --> 00:03:25,230
this can be useful things like for example as I just said, session data for a user of your website

43
00:03:25,440 --> 00:03:30,090
or maybe in an online shop where you want to clear the cart after one day,

44
00:03:30,090 --> 00:03:35,130
so whenever you have a use case where data should clean up itself, you don't need to write a complex

45
00:03:35,190 --> 00:03:36,290
script for that,

46
00:03:36,300 --> 00:03:43,960
you can use a time to live index with that expiry after seconds addition we added in our index.

47
00:03:43,980 --> 00:03:45,650
Important to know here by the way,

48
00:03:45,840 --> 00:03:48,260
you can only use that on single field indexes,

49
00:03:48,270 --> 00:03:53,760
it does not work on compound indexes and as I mentioned, it works on date objects.