1 00:00:00,180 --> 00:00:05,580 In the last couple of videos we've spent our time inserting documents into the database right here as 2 00:00:05,580 --> 00:00:06,270 an example. 3 00:00:06,270 --> 00:00:12,870 This code inserts three documents into the tasks collection each task has a description and completed 4 00:00:12,900 --> 00:00:13,850 field. 5 00:00:13,860 --> 00:00:20,160 Now when we viewed that data over in robo 380 we saw all of our descriptions and all of our completed 6 00:00:20,160 --> 00:00:26,670 values along with one additional field which we did not specify underscore I.D.. 7 00:00:26,670 --> 00:00:33,090 Now I briefly mentioned that this field is automatically created by Mongo D.B. and it stores a unique 8 00:00:33,090 --> 00:00:37,050 identifier for each document you insert into the database. 9 00:00:37,080 --> 00:00:43,320 In this video before we go any further I want to take a little time to talk about the value inside. 10 00:00:43,320 --> 00:00:48,990 We're gonna talk about what object ideas are why they're used and how they're going to play an important 11 00:00:48,990 --> 00:00:50,880 role in Mongo D.B.. 12 00:00:50,880 --> 00:00:56,070 Now the value we're seeing here for the I.D. is much different than what we would see in a traditional 13 00:00:56,100 --> 00:00:57,780 Eskew l database. 14 00:00:57,840 --> 00:00:59,570 And this is by design. 15 00:00:59,640 --> 00:01:06,420 So in an essay you old database like my ask you l these server generates the I.D. for new records and 16 00:01:06,420 --> 00:01:11,800 it follows that auto incrementing integer pattern where the first record has the idea of one. 17 00:01:11,820 --> 00:01:21,110 The second two three four and so on with Mongo D.B. the ideas are known as G you I.D. which stands for 18 00:01:21,120 --> 00:01:25,010 globally unique identifiers and these are a bit different. 19 00:01:25,050 --> 00:01:30,360 They're designed to be unique using an algorithm without needing the server to determine what the next 20 00:01:30,450 --> 00:01:37,320 I.D. value is switching from auto incrementing integers over to globally unique identifiers allowed 21 00:01:37,320 --> 00:01:44,010 Mongo D.B. to achieve one of its main goals which is the ability to scale well in a distributed system. 22 00:01:44,010 --> 00:01:50,160 So we have multiple database servers running instead of just one allowing us to handle heavy traffic 23 00:01:50,220 --> 00:01:55,300 where we have a lot of queries coming in with Mongo D.B. and new ideas. 24 00:01:55,350 --> 00:02:01,870 There's no chance of an IED collision across those database servers with an auto incrementing integer. 25 00:02:01,890 --> 00:02:07,680 It's definitely possible that we could have a user with an I.D. of one in one database server and a 26 00:02:07,680 --> 00:02:13,680 user with an I.D. of one in another database server and we could eventually run into an issue where 27 00:02:13,680 --> 00:02:18,530 those ideas conflict with Mongo D.B. we don't run into that problem. 28 00:02:18,540 --> 00:02:24,510 Another great advantage is that we can actually generate the ideas for our documents before we ever 29 00:02:24,510 --> 00:02:26,420 insert them into the database. 30 00:02:26,640 --> 00:02:32,610 So our server doesn't need to be the one who generates the I.D. we can actually use that Mongo D.B. 31 00:02:32,730 --> 00:02:36,420 library to generate object ideas of our own. 32 00:02:36,420 --> 00:02:37,880 And that's where I want to start. 33 00:02:37,950 --> 00:02:44,370 We're gonna generate some object I.D. using node j s then we'll dissect them and explore exactly what 34 00:02:44,370 --> 00:02:44,950 they're made of. 35 00:02:45,120 --> 00:02:49,190 Let's switch over to visual studio code and get this process started. 36 00:02:49,200 --> 00:02:54,570 The first thing I'm gonna do is comment out our call to insert many down below where we insert into 37 00:02:54,570 --> 00:02:56,190 the tasks collection. 38 00:02:56,190 --> 00:03:01,500 The reason I'm commenting this out is that I don't want to insert these same tasks again when the file 39 00:03:01,500 --> 00:03:03,000 runs for the moment. 40 00:03:03,000 --> 00:03:06,280 We're not actually going to change the database in any way. 41 00:03:06,360 --> 00:03:12,870 What we're gonna do is grab something else off of Mongo D.B. B that allows us to work with object I.D. 42 00:03:12,900 --> 00:03:15,880 So down below where we set up Mongo client. 43 00:03:15,990 --> 00:03:22,370 I can create a new constant for a capital O object capital I capital D. 44 00:03:22,710 --> 00:03:29,250 And we're going to get the value for that off of a property on mongo D.B. with the exact same name object 45 00:03:29,340 --> 00:03:30,430 I.D.. 46 00:03:30,480 --> 00:03:36,060 Now you'll notice here that we're grabbing a lot of individual things off of Mongo D.B. and we're storing 47 00:03:36,060 --> 00:03:38,220 those and individual variables. 48 00:03:38,220 --> 00:03:42,930 This is a great use case for disk structuring which we covered earlier in the class. 49 00:03:43,020 --> 00:03:47,950 So as an example we could achieve the exact same thing with the following code. 50 00:03:47,970 --> 00:03:52,890 I'm going to comment out this code so we can leave it in place and what we're going to do is create 51 00:03:52,890 --> 00:03:53,960 a constant. 52 00:03:53,970 --> 00:03:59,580 Now we know we get an object back from require Mongo D.B. and we know it's an object because we've been 53 00:03:59,640 --> 00:04:01,530 accessing properties on it. 54 00:04:01,530 --> 00:04:08,190 So right here we'll just de structure that I'm going to grab Mongo client and I'm also going to grab 55 00:04:08,250 --> 00:04:09,870 object I.D.. 56 00:04:09,870 --> 00:04:12,450 Now where am I going to grab them from an object. 57 00:04:12,450 --> 00:04:19,170 That's how d structuring works and I have the object as the return value for calling require with Mongo 58 00:04:19,220 --> 00:04:21,010 d be perfect. 59 00:04:21,030 --> 00:04:25,610 So this is just a shorthand for grabbing things off of Mongo D.B.. 60 00:04:25,860 --> 00:04:30,650 Now the old code is still going to work exactly the same Mongo client and that connect is still going 61 00:04:30,650 --> 00:04:32,090 to work as expected. 62 00:04:32,220 --> 00:04:38,230 But now we're gonna be able to generate our own ideas right here from the file and to do that. 63 00:04:38,250 --> 00:04:41,600 Let's start by creating a variable to store the idea. 64 00:04:41,670 --> 00:04:45,680 Then we're going to use object I.D. which we just grabbed. 65 00:04:45,690 --> 00:04:47,330 Now that's a constructor function. 66 00:04:47,370 --> 00:04:53,730 So we use it with the new keyword that is new object capital I capital D. 67 00:04:53,970 --> 00:04:57,040 And we call it providing no arguments. 68 00:04:57,060 --> 00:05:03,600 This is a function that's going to generate a new for us now the new keyword is technically optional 69 00:05:03,810 --> 00:05:08,970 because the Mongo DB library has a little defensive programming built in to add it. 70 00:05:08,970 --> 00:05:14,290 If you don't but it's in general a good idea to add it in ourselves down below. 71 00:05:14,370 --> 00:05:19,310 We can now do something with this I.D. and all I'm going to do is dump it to the console. 72 00:05:19,350 --> 00:05:23,840 So for me console dialogue printing I.D. to the terminal. 73 00:05:23,850 --> 00:05:27,990 Now that we have this in place let's go ahead and test things out down below. 74 00:05:27,990 --> 00:05:33,690 We are running commands from the task manager directory and we're just going to run this file once again 75 00:05:34,110 --> 00:05:38,590 right here node space Mongo D.B. Deighton J. 76 00:05:38,590 --> 00:05:40,950 S and when I run it what do I get. 77 00:05:40,950 --> 00:05:44,200 I get a brand new object I.D. showing up. 78 00:05:44,340 --> 00:05:49,770 Now you'll notice that once again the program is hanging because we do have that open connection. 79 00:05:49,770 --> 00:05:52,890 We can always use control C to shut that down. 80 00:05:52,890 --> 00:05:55,860 Now let's talk about the I.D. value itself. 81 00:05:55,890 --> 00:06:01,300 What we have here is not just one long randomly generated series of characters. 82 00:06:01,380 --> 00:06:06,630 There's actually a few different pieces of information inside of here embedded in there for example 83 00:06:06,660 --> 00:06:10,910 is a timestamp and we can learn more by heading over to the browser. 84 00:06:10,920 --> 00:06:15,510 Now you don't need to pull up the following web site since we're only going to use it for a brief moment 85 00:06:15,540 --> 00:06:19,080 as a visualization to see what I'm talking about. 86 00:06:19,110 --> 00:06:26,370 I'm going to Google Mongo D.B. object I.D. and we're looking for their object I.D. documentation on 87 00:06:26,370 --> 00:06:27,790 the reference site. 88 00:06:27,810 --> 00:06:32,500 So right here that is the reference documentation as opposed to the API docs. 89 00:06:32,580 --> 00:06:38,820 And when we pull that up it's gonna give us a breakdown of what exactly an object I.D. is made of right 90 00:06:38,820 --> 00:06:46,110 here and object I.D. is a 12 byte value which consists of the following the first four bytes of the 91 00:06:46,110 --> 00:06:50,760 object I.D. represent the number of seconds since the Unix epic. 92 00:06:50,760 --> 00:06:57,540 So that is a point in time which has been decided upon and that is midnight January 1st of 1970. 93 00:06:57,570 --> 00:07:03,900 So embedded inside of all of your object I.D. is actually a timestamp which knows when the particular 94 00:07:03,930 --> 00:07:10,670 object I.D. was created which can be of great value in the long term as your dataset grows. 95 00:07:10,740 --> 00:07:15,140 Next up after the first four bytes we have the following five bytes. 96 00:07:15,150 --> 00:07:18,030 These are a randomly generated value. 97 00:07:18,090 --> 00:07:22,320 And the last three bytes are a counter starting with a random value. 98 00:07:22,320 --> 00:07:28,080 Now when we put all this together we have a very complex algorithm that allows us to generate a globally 99 00:07:28,140 --> 00:07:33,570 unique I.D. without needing a central authority to tell us what the next I.D. is. 100 00:07:33,570 --> 00:07:39,960 And we just saw that since we generated an object I.D. inside of our node j s code. 101 00:07:39,960 --> 00:07:45,570 Now I'm going to close down this tab and we're going to head back over to the API documentation down 102 00:07:45,570 --> 00:07:48,240 below under O for object I.D.. 103 00:07:48,330 --> 00:07:50,010 There is indeed an entry. 104 00:07:50,010 --> 00:07:53,910 And if we click that we can explore some of the methods available to us. 105 00:07:53,910 --> 00:07:59,850 And the only one we're really going to use and we're only going to use it for this example is get timestamp 106 00:08:00,270 --> 00:08:07,690 get timestamp gets the timestamp that's stored inside of the first four bytes for that object I.D. and 107 00:08:07,710 --> 00:08:11,670 we can go ahead and use this method to actually print those out. 108 00:08:11,670 --> 00:08:20,310 So right here we're going to add another console dot log line down below console dot log I.D. dot get 109 00:08:20,700 --> 00:08:26,850 timestamp and we are going to call that as a function which it is and the documentation says it doesn't 110 00:08:26,850 --> 00:08:30,860 need to take any arguments and we're going to get our timestamp back. 111 00:08:30,870 --> 00:08:36,060 So what I'm going to do is save the program and rerun it to view the timestamp right here I'll shut 112 00:08:36,060 --> 00:08:38,190 things down and rerun the script. 113 00:08:38,220 --> 00:08:39,120 And what do I get. 114 00:08:39,120 --> 00:08:44,780 I get a timestamp right here I can see the current point in time which is indeed accurate. 115 00:08:44,820 --> 00:08:51,300 And right here I have the exact hour minute and second and if I shut the script down and I rerun it 116 00:08:51,570 --> 00:08:53,580 you can see it's updated a little bit. 117 00:08:53,580 --> 00:08:58,770 We went from the forty ninth minute to still the forty ninth minute but we were at thirty four seconds 118 00:08:58,800 --> 00:09:01,610 into the minute earlier and the second time I ran it. 119 00:09:01,620 --> 00:09:03,910 We were at forty seven seconds. 120 00:09:03,960 --> 00:09:11,100 So as we generate new ideas either on our own or as Mongo D.B. generates them for us a timestamp is 121 00:09:11,100 --> 00:09:16,020 indeed embedded right inside of there allowing you to know when it was created. 122 00:09:16,020 --> 00:09:21,800 Now let's go ahead and use our generated object I.D. as the actual I.D. for a new document. 123 00:09:21,810 --> 00:09:28,170 We insert so down below I have the first insert one call we explored a couple of videos ago. 124 00:09:28,170 --> 00:09:33,480 I'm gonna take that entire call and uncommon to it and we'll just change up the data a little bit. 125 00:09:33,480 --> 00:09:34,820 Right here I have the name. 126 00:09:35,070 --> 00:09:41,040 I'll change that over to Vikram and I'll change the age as well to something like twenty six. 127 00:09:41,040 --> 00:09:46,250 Now alongside of the two fields we're also going to specify underscore I.D.. 128 00:09:46,530 --> 00:09:53,790 And we have to provide if we're choosing to set underscore I.D. an object I.D. we already have one created 129 00:09:53,790 --> 00:09:59,250 and stored in the I.D. variable so I can go ahead and reference that right here. 130 00:09:59,250 --> 00:10:03,580 Now let's go and save the program to rerun things when we rerun it. 131 00:10:03,610 --> 00:10:08,650 We're gonna see our new I.D. printed to the terminal and then we're gonna be able to compare that with 132 00:10:08,650 --> 00:10:13,380 the I.D. we see over in rowboat 3 t when we view our document. 133 00:10:13,390 --> 00:10:15,760 So right here I'll shut it down. 134 00:10:15,850 --> 00:10:17,140 I'll start it up again. 135 00:10:17,140 --> 00:10:18,960 And we have our data showing up. 136 00:10:19,300 --> 00:10:25,090 So we have the actual data that came back from the server as the result of the operation and it matches 137 00:10:25,090 --> 00:10:27,990 up perfectly with the I.D. we have right here. 138 00:10:28,030 --> 00:10:34,630 If we had over two robo three T we'll be able to see the exact same value in that user's collection. 139 00:10:34,720 --> 00:10:41,650 I'm going to refresh the page using command or control are and right here we do indeed have the exact 140 00:10:41,650 --> 00:10:46,600 same I.D. that we had just generated over inside of the terminal. 141 00:10:46,600 --> 00:10:52,420 Now there's just one more thing I want to talk about related to object I.D. before we wrap up for the 142 00:10:52,420 --> 00:10:52,960 moment. 143 00:10:52,960 --> 00:10:58,840 I'm going to remove that I.D. property and I'm going to comment out in this example once again I just 144 00:10:58,840 --> 00:11:04,140 set that up to show you that you can provide your own object I.D. If you want to. 145 00:11:04,150 --> 00:11:09,940 Now for our purposes we're not going to do that because it's just extra code we can have Mongo D.B. 146 00:11:10,140 --> 00:11:12,460 automatically generate it for us. 147 00:11:12,460 --> 00:11:19,210 And in most cases we don't need to know the object I.D. value before the document is inserted. 148 00:11:19,210 --> 00:11:25,030 But if you needed to you could write here the last thing we're going to talk about is how object I.D. 149 00:11:25,060 --> 00:11:31,330 are stored because that plays an important role as well in the terminal when we see an object I.D. we 150 00:11:31,330 --> 00:11:34,060 just see these series of characters that make it up. 151 00:11:34,120 --> 00:11:39,190 So right here we have an I.D. that starts with five C and ends with 7 1. 152 00:11:39,220 --> 00:11:45,550 Now over in robo 3 T we have the exact same I.D. that starts with five C and ends with seven one for 153 00:11:45,550 --> 00:11:47,810 the new document we just created. 154 00:11:48,040 --> 00:11:50,750 But there's also some extra stuff on each end. 155 00:11:51,010 --> 00:11:57,430 What we have here is a function call where this string is being provided as the first and only argument. 156 00:11:57,820 --> 00:12:05,230 So this is a visualization making it easier to see the object I.D. value because I.D. are indeed a binary 157 00:12:05,290 --> 00:12:06,010 data. 158 00:12:06,010 --> 00:12:12,570 Now the reason they're using binary data over a traditional string has to do with the size of each. 159 00:12:12,580 --> 00:12:19,120 By using binary instead of a string they're able to cut the size of an object I.D. in half and we can 160 00:12:19,120 --> 00:12:20,230 quickly prove that. 161 00:12:20,230 --> 00:12:24,560 Just to explain exactly why this is the way they chose to go about things. 162 00:12:24,630 --> 00:12:31,900 So over inside of our code we have this I.D. variable that actually has an I.D. property on it. 163 00:12:31,960 --> 00:12:34,930 This contains the raw binary information. 164 00:12:35,040 --> 00:12:40,210 But I'm going to do is take a quick moment to save the file and rerun it just so we can see that I'll 165 00:12:40,210 --> 00:12:41,490 shut things down. 166 00:12:41,530 --> 00:12:42,740 Start them up again. 167 00:12:42,790 --> 00:12:46,780 And right here we have our buffer with the binary data inside. 168 00:12:46,840 --> 00:12:53,080 Now we can check the length of this by using I.D. dot I.D. dot length and right here we're going to 169 00:12:53,080 --> 00:12:59,170 see if we rerun the program that the length is indeed at 12:00 which matches up exactly with what we 170 00:12:59,170 --> 00:13:05,710 explored in the documentation before we have that 12 byte value where we have the timestamp the random 171 00:13:05,710 --> 00:13:09,040 value and we have the incrementing value at the end. 172 00:13:09,040 --> 00:13:13,960 Now if we were to convert that from binary into a string it would double in size. 173 00:13:13,960 --> 00:13:20,410 So right here we can do just that using a method available on object I.D. if we head over to the API 174 00:13:20,410 --> 00:13:26,150 docs for one final time and we already explore to get timestamp to do what we want to do. 175 00:13:26,170 --> 00:13:32,110 We're gonna use two hex string which is going to convert it over to its string representation. 176 00:13:32,140 --> 00:13:40,810 So right here to get that done we'll use console dot log I.D. dot to hex string we're gonna call that 177 00:13:40,840 --> 00:13:47,000 as a function that's going to return the string representation and we're gonna do is check its length. 178 00:13:47,050 --> 00:13:52,960 So right here we're printing the original object I.D. length then the length of the string representation 179 00:13:53,290 --> 00:13:59,020 I'm going to save the program I'm going to shut things down I'm gonna restart it and right here we can 180 00:13:59,020 --> 00:14:05,110 see that the original representation was just 12 while the string representation was double in size 181 00:14:05,140 --> 00:14:06,670 at twenty four. 182 00:14:06,730 --> 00:14:13,030 So this is the reason we are seeing object I.D. all around it is just a way to visualize easier for 183 00:14:13,030 --> 00:14:13,570 humans. 184 00:14:13,570 --> 00:14:15,420 What exactly is happening. 185 00:14:15,460 --> 00:14:21,520 So here it's giving us the representation as a string but it's wrapping it in this object I.D. call 186 00:14:21,730 --> 00:14:27,400 to let us know that it's not actually a string it's what comes back from this function call which would 187 00:14:27,400 --> 00:14:34,150 be binary data but to save us a lot of time and to save us from some really long lines in our table 188 00:14:34,360 --> 00:14:39,470 all of that is abstracted away from us the end user of Mongo D.B.. 189 00:14:39,730 --> 00:14:44,620 Now you might be wondering why did we just spend so much time learning about ideas we were just getting 190 00:14:44,620 --> 00:14:50,980 into the fun stuff and the reason is that we need to know about object I.D. in order to be able to fetch 191 00:14:50,980 --> 00:14:56,430 our documents by I.D. which is something we're going to do in the very next video. 192 00:14:56,500 --> 00:14:59,060 So that's it for this one and there's no challenge here. 193 00:14:59,110 --> 00:15:05,230 I just wanted to give you a little background on what exactly is going on with I.D. in Mongo D.B. in 194 00:15:05,230 --> 00:15:06,060 the next video. 195 00:15:06,070 --> 00:15:10,780 We'll get back to exploring the database and you'll learn how to fetch your documents out of it. 196 00:15:11,080 --> 00:15:13,050 Let's go ahead and jump right in.