[MUSIC] We've talked about NoSQL databases, primarily from the point of view that they're simple key value stores, where we have a key and we have a value, and the database doesn't really care much about the value. Well, let's talk a little bit about a different type of database that's a document oriented database. So, when we have documents, we can have a database like MongoDB, which we're going to be talking about, that can view a, a value that's stored in it as a structured document that has different properties or fields. So, MongoDB is a document orientated database, and we can use it in Spring, just like we have other databases that we've connected to. The In-memory databases that we've been using for the examples. But, we can simply, doing a little bit of work, we can swap out that in-memory database. And use a much more powerful data store like Mongo. Now, to do this, it's helpful to understand a few of the concepts. One of the concepts is that natively internally Mongo views documents as JSON objects or BSON as is what it uses internally or calls its documents. But you can think of them as essentially JSON objects that are being stored. So when you go and you put in a key, the value for this key is going to be JSON that's being stored in the database. So just like you had before where you could go and look up and object by a key, you can still do that, except that you have, know that what you're looking up is a document that has a JSON like structures. They call their BSON, but it's essentially a JSON like structure. Now, this is really nice because we're very familiar and, and understand how JSON objects work after going through all of the different spring examples that we've been working with. So now we can take the concepts of how we've been marshalling objects in JSON, and we can move that into our database as well, and begin thinking about how we go and do searches on the database and store things in terms of JSON like objects. Now, it may seem like it's going to take a lot of work to get from the, the video service, and the other applications that we've been building so far, to something that's connected to MongoDB. But what we can see is that the distractions that we have, where normally we have our application that we produce, and then we're sitting on top of Spring data. And our repositories, so we might have one or more repository interfaces here that we're using from spring data. That spring data can isolate us from a lot of the changes of the underlying database. So if we've been using this HSQLDV that maybe in memory, we can suddenly swap to Mongo and spring data can isolate us from a lot of those changes to our application. You would think you would have to make in order to make that switch. And the other part of this that's helping us to do that separation is this idea of you know, object relational mapping to a database or mapping our objects into a database. Because you can think about it, we, we're, we've gotten really good at using Jackson to map our objects into JSON. We've gotten really good at using spring data, and the repositories, and JPA to map our objects into database rows and columns. But with Mongo, we can simply switch over and begin having spring data map our objects into the documents that Mongo cares about. Now, one thing that I should also mention, before we get too much farther along here, is that, because Mongo is a document orientated database, it doesn't have this concept of a strict schema that has to be adhered to. So, the values, as long as they fit the, the sort of JSON, or VSON model, that Mongo's using underneath the hood. They can have any number of properties and be flexible. So they still fit this noSQL model, gret flexibility in what we're storing, being able to change things over time. So, what we're going to do now is let's take a look at the actual code and the changes that we need to make to the video service that was built on top of spring data rest. And see what we get and how we get to Mongo DB. So, the first thing we're going to do, is we're going to open up the application class that we've seen in all of these examples. And it looks very similar to what we've seen before. We still have a repository rest in VC configuration. So we know that we're going to be using Spring Data Resp to serve data out of the database, and to give it a restful API. We still have our original date video service API for the client. That allows the client to find particular videos by name or duration. Go and list the different videos that are in the repository. And then if we go and look at our repository, we're going to begin to see something slightly different. So if you'll remember before, when we were using JPA, we were extending a CRUD repository. Now, the one of the main changes that we're going to have to make in order to switch over to Mongo. Is we're going to have to tell Spring to begin using a Mongo repository instead of a CRUD repository. Now, we're having to change our code, but the nice thing about this is, that all of the users of the interface from a, from a, a used user inner you know, approach to using that interface, there's no real difference in what we're going to be changing. So we're not changing individual methods or return values on this interface, all we're doing is changing the interface that this interface extends. So, the classes that depend on this interface wouldn't be impacted by our change of switching from one database to Mongo. So this is one of the nice things that we're getting from Spring Data, is that this abstraction layer is helping to separate us from the details of the individual database and allow us to decide. We, we know longer want to target this database we want to target this database without breaking all of the users of that particular repository interface. So, as we'll see, we still have all of the same things that we had before. We still have the annotations and the same parameters for Spring Data Res, we're still passing parameters the same way. And we're still inheriting the normal find methods and delete methods and other things from the parent repository that we're extending. Now the other change we have to make is we have to go and update our video object to no longer use the JPA annotation, but instead to include the annotations for Spring Data Mongo. And in, in this case it's actually quite simple to do this, because all we have to do is to have one annotation in order to get our videos stored in Mongo DB and that's to add an add ID annotation. When specifies the member variable that we want to be the key when we're storing these objects in the database. So with very little change, all we're doing is taking changing the annotations in our video objects, and then if we go and look at the repository, we're changing what we're extending. But all of this is working within the same framework that we've gotten used to with Spring Data and Spring Data Res. We're just slightly changing how we're annotating and how we're extending this interface, but we're still not implementing the interface, trying to figure out how we go about, in change and use queries for MongoDB. From the, the programmatic point of view of storing objects and retrieving objects, we're still doing all of the same things that we did before with spring data, and we're still exposing all of these objects via spring data reps. So, this is the beautiful thing again. By using spring and spring data, we're, separating us from the details of these underlying databases. And how we query them, and, and deal with the different variations in their representations. But, we also gain all of these benefits of, one person is going to go, an, an expert presumably, is going to go and create the different mappings down to these databases. We also gain from their domain knowledge of knowing the right way to go from objects to the particular database. So we can reuse all of this, this great knowledge from the domain experts to know how to do this translation layer down to each individual database. So, this is the complete application for Spring MongoDB. If you want to go through and add some extra customization, you don't have to have this annotation but we have the at enable Mongo Repositories. And if you wanted to go and configure some of the ways that Mongo DB gets setup, you can add this to your application class. And then again setting it up. One of the other small changes that we have to make is in our build.gradal file. We have to go and add the dependency. For the MongoDB database driver and other dependencies that are needed by Spring. And then the final thing that's helpful to people is this example is going to assume that you're running the database locally. But if you decided that you wanted to go and connect to a remote database. There is an applications.properties file underneath source main resources, and if we go and look at that file, we see that we have the ability to change the database host where this MongoDB database lives, as well as the port. Now, or we could go and specify the connection URI with user name and password, or a specific database that we wanted to connect to. So, what we've seen from this is, is that spring data, and spring data rest gave us this great abstraction that protects us from complicated changes when we decide to switch between databases. Now there may be circumstances where things are hard to map into another database, and it may not fully protect us to those things. But in most cases we can simply switch to the appropriate subset of spring data that we want to use for the particular database that we want. And spring data can figure out the right way to map our objects into that new database. So in this case, by simply adding the at id annotation to our video and changing the, the, the annotations describing how we want to persist that object. And by changing, slightly our repository interface to extend a different interface rather than crud repository. Suddenly we're able to take our objects and automatically map them into the documents that Mongo DB stores.
