[MUSIC] Hello, and welcome back. In this lecture we will take a look at document class, fields, field types, aliases and also custom fields with examples. So what is a document? Documents are the core objects in Mongoid. They can be stored in a collection or they can be embedded in other documents. So you can have a standalone movie, a standalone actor or you could have a movie which could include or embed actor documents. Now we will talk more about this in our relationships topic, which is really all about linking and embedding. But for now, basically documents are nothing but your data that can be stored in a collection. Now documents have field so in Mongoid we have say, a class movie and any of your document like actor, movie, place and so on, can have field, right? Just like your object oriented programming or any of your models. Will have field, title, type, you can give a type, and we'll talk about different types in a few minutes. You can also have custom types. But basically title is a string, type is a string, rated is a string in this example, e is an integer. And you can also bring in location which is going to be a custom type. But basically you can go and define your model with a whole bunch of different fields. Now one thing to remember is it is string by default. So when you define a field and if you don't assign a type, it automatically is defaulted to a string. Now speaking of the defaults, it's important to note that when you use the model generator which is rails g model and if you don't provide a default type, only then you will get the type equal to string as the default. Now if you're simply typing a class right-click and then create a new class and then start typing it in your editor. And if you don't provide a type, say you just say field :title then the type is called quote and quote typeless. Now also notice that there is, you can compare this with active record and you can clearly see that active record which is more often ORM versus Mongoid which is more of an ODM. Which basically means that the active record declared no attributes within the model class. So they were kind of magically applied through what we call a centralized schema class, and then you did a schema migration. But in Mangoid, you don't have this concept of migrations. So you basically go and and define all the different fields that you need, which will map to the field in your JSON document. So in this example, we have a movie in this little example which means you will have field like title, type rated here which when you create and save a movie from your rails console from your web application that will get map to the data, your movie JSON document with the following four fields. Now you've seen the scaffold command in the zips example. But basically to create a model you can use a rails space g model command. I'll show this command in a minute here. But basically when you do this when you have your Mongoid gem in your Gemfile. Rails g model by default will do all the wiring for Mongoid. In other words, adding the Mongoid gem makes the Mongoid the default ORM but of course, you can switch it back to whatever you want. Meaning you can always go back and change it within your application.rb file, which I'll bring up in a minute and show you where exactly the wiring happens. So just to give you an example of how rails g model might look. So here is a couple of examples. So directly taken from our movie application which we will discuss in a few minutes. We will do a setup in our upcoming lecture where I'll go through all of the different things. But basically rails g model then you give the name of the class of this movie here and you define all the different types that you want. So here's a title which is title type rated year is an integer, release date is a date. Similarly we have Actor name, birth_name. So this is again, defining all the different fields for your class. So just to look at the model that we just created. So the rails g model for the movie class will actually go and create this file for us with all the field and all the different types. So notice how we have String and Integer. We also have things like Measurement, which we haven't covered, we'll talk about this later on in this lecture. And while we are looking at this class, let's also go and look at the application.rb which is where all the wiring will happen like loading and connecting to the database, the collection. So this is exactly how the application.rb will load bootstraps mongoid within the applications. So line 24, is the one that'll actually load the mongoid.yml file. And this from our previous lecture that this is where we have all the tests and the development and local host and port number and all that. So this is how exactly the wiring happens and when the application starts, you have this connection to the database, your test database and your application is ready to go, to hit the data base and get the data, insert and update and do all kinds of things you need to do. Now these are all the different field types, Array, Boolean, DateTime, and all that. Now this is not necessarily anything special for Mongoid, this is more of a MongoidDB, and what the MongoidDB, the Ruby driver supports really. Mongoid just lets you identify what your attribute should be, and will do the appropriate check that it has to do as part of your application and data processing. Now one other difference between Mongoid and active records is timestamp. Now timestamp information is not added by default in Mongoid as it is within the ActiveRecord. So the two created_at and updated_at fields are done via the Mongoid::Timestamps mixin. And I'll show you this in a minute with an example. And of course you can use the touch which will update the documents updated_at timestamp. So if you make some change you can do a touch on the document and it will basically update the time stamp. So here is the example. Here is the mixed in Timestamps. So we have added this into our movie. So now you should be able to look at created_at, updated_at. We can do a touch. So let's go ahead and take this class movie for a quick spin just to understand some of the basics, before we actually do more detailed in upcoming lectures. So you know find from the previous lessons? So one of the basic things you can do is just do a movie.find with the name of the ID and you will get the movie information. So this is using the movie object. The movie class we go into a movie.find. So let's go and look at the timestamp now. So let me first clear the screen. Okay, to demonstrate timestamp, I will first go and create a simple movie, movie.create. So let's call this movie "Rocky XXVI". And it's a movie I'm creating. So our movie was created successfully. So now I can call the created_at on this movie 26 object, and I'll get back the time as you can see it was done at this date. I can also do an updated_at. Which will be exactly the same because it was created_at that time and updated_at that time because obviously, it was done at the same time. But we can always test this by really quickly going and changing some day down this rocky26 movie in the collection. So let's go and do that and see if our updated will show a different time or not. So we have a field called year. If I go and change that to 2015, I will just change the name of the year 2015, so that should change our updated_at to the different time. So now our updated_at and created_at is still showing the exact same time. And this is something we'll talk about a little more in depth later on. Because this data is not saved yet, so you have to do a .save on this object to actually see the change in the data. So notice how again, I chained the year to 2015 but it's still showing me the same date, both created_at and updated_at. That's because the .save needs to be called. So let's do that. So rocky26.save, that was good. So now if I go back and do a created_at, still same. 22:28, this is when the object was created. Updated_at should show us at different times. At 22:31, where it says 22:28, that's our little timestamp update there. Now touch will basically will chain the updated time, so if I simply go into a touch that should chain the time as well. So if I go back and look updated_at, notice our 22:31 became 22:32, so touch will actually go in. Now we will come back and look at the touch later on once we do relationships, because there is a propagation property which is pretty cool. So when you have multiple relationships like actor with the movie and a writer and director and all that. So the touch will actually cascade the updated app so all the others also get updated. So will do that later once we've covered relationships. Let's take a look at field aliases. Now this is a very useful and a helpful feature. And here's an example in line number six. So say we have birthName in the Actor, as: :birth_name, so we have one as your camel case, and then one we have your snake case. Now what are some of the advantages? Well one thing is that it will help you with the compression. So when you have lots of data in your document, lots of different elements in your document, it will help you with your compression by giving a different name, a shorter name maybe. But the other big thing is the Rails naming convention compliancy. Rails uses snake case so if you're a pure Rails developer and you want to comply with your naming conventions and all that then this another big advantage where you can go and define an alias. So how this is an alias and how does it work from a Rails console standpoint? Let's take this for a simple quick demo and see what happens. So I should be able to go and do something like actor.find, send in the ID.birthName, and I will get the data back. And I can also do birth_name, so I can use the model or the alias and I will still get the same data. So in this example, I'm trying to find this actor with this ID with the tag birth_name and I still get the same data. So that's a good example of using an alias. Next, let's take a look at the custom fields. So here's an example called, a class called measurement. So in this example what we have is in our movies we have say instead of having one single property called 60 minutes, they lent us a movie. It's 120 minutes or 2 hours. Meaning you're combining a number two with string or minutes or mins, hrs, whatever. In sort of doing that to make our application more efficient and easy from a UI standpoint. You could make something more like a custom class to handle data like amount equal to 60 or units as minutes. So that the client application could query based on hey, give me all the movies which are are greater than 120 or show me all the units. So you can do a more custom search and this would be much more helpful to do your processing. So custom feeds are very handy and we have a couple in our project. We'll talk about that later on. But basically, the other important thing with custom fields is that you will define five methods in total. Initialize, mongoize, and demongoize, evolve, and so on. But basically, what these are is primarily to serialize and deserialize the data. Let me show you what I mean by this. So here is our class measurement. And then as I said, we are handling the amount and the units at 2 hours or 120 minutes basically, and then you will have to implement a mongoize method which will create a DB form of the instance. And then the other one would be exactly the opposite, the demongoize which will create an instance of a class from the DB form of the data. So one is going into the database, the other one is coming out of the database. And then all the way all at the bottom, you have the evolve method which is used by criteria to convert objects to DB-friendly form. So you will have logic to actually convert the object into a Mongoid DB-friendly form. Finally, let's take a quick look at store_in. Now store_in is nothing but an application type to a document type mapping. What I really mean by that is, say you have a location class and you know this from the previous examples. When you do a save or store location it'll automatically go to the location collection. But what if we want to store a location in places collection? Then we bring in this line number three and say store_in collection: "places". So when you do your new location, that'll actually get saved into places. Let's go and give a quick try and see what actually happens with this store end collection. So let me demonstrate this by doing simple example here. Again, we'll talk about place a lot more in detail later on but this is just to demonstrate storing content. So lets say I do a Place.count. We already have a collection.place, and it comes back with 380 documents in this collection. So let's go and add a new location, which will go and actually store in the place, and we will see what happens. And it has to increment by 1, and we should hit 389. And so I'll go and paste in Location.create, which will actually instantiate and also persist the data. So I went and randomly created a city, state and country. Let's not worry about the data, just insert something. Now if I go back and do a place.count command recall. I should see 389, so notice how would actually incremented by one. So there's no mention of places anywhere here. It's not a Place.create, it's a Location.create but the fact that it was a store in Momgoid told MongoDBA here is the data that you want to store and collect in the place collection. Just to summarize this topic, I think we saw a lot of good stuff, document, custom field, aliases, timestamp, updated app and all that. And the next we will go into the CRUD and we will apply some of these Mongoid concepts to our CRUD topic that we have covered in previous lessons. Thank you.
