In this course, we will explore MongoDB, a very popular NoSQL database and Web Services concepts and integrate them both with Ruby on Rails. MongoDB is a used to handle documents with a pre-defined schema which will give the developers an ability to store, process and use data using it’s rich API. The modules will go in-depth from installation to CRUD operations, aggregation, indexing, GridFS and various other topics where we continuously integrate MongoDB with RailsRuby. We will be covering the interface to MongoDB using the Mongo Ruby API and the Mongoid ORM framework (the MongoDB access counterpart to RDBMS/ActiveRecord within Rails). The last portion of the course will focus on Web Services with emphasis on REST, its architectural style and integration of Web Services with Rails. Core concepts of Web Services like request/response, filters, data representation (XML/JSON), web linking and best practices will covered in depth. This course is ideal for students and professionals who have some programming experience and a working knowledge of databases.
Document Class
Loading...
Del curso dictado por Johns Hopkins University
Ruby on Rails Web Services and Integration with MongoDB
294 calificaciones
Johns Hopkins University
294 calificaciones
Curso 3 de 6 en SpecializationRuby on Rails Web Development
De la lección
Mongoid
In this module, we’re going to explore Mongoid, which is an Object-Document-Mapper (ODM) for MongoDB written in Ruby. We will learn to integrate Mongoid with Rails and work to understand document and relationship mapping, as well. We will work on a number of queries using the Mongoid API and wrap up the module by implementing Rails/Mongoid Model View Controller.
Conoce a los instructores
Kiran ChittargiAdjunct Professor, Graduate Computer Science
Whiting School of Engineering
[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.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2019 Coursera Inc. Todos los derechos reservados.
