Migrations are one of Rails’s strong suits. They keep track of the evolving structure of the application’s database. In this lesson we’ll consider a small change to the already existing features and implement it directly with a migration.
1.Introduction2 lessons, 14:01
2.Building a Rails Application11 lessons, 2:09:35
3.Conclusion1 lesson, 02:23
In this lesson we're going to add a new feature that actually impacts the configuration of our database. We're going to generate a new migration. A migration is a file that basically manipulates your database in order to suit whatever it is you're trying to implement. For this particular context I'm gonna go to the DBschema.rp file, which basically contains the entire definition of the database. Let me just fold this comment so we can get a full look at our schema. We have a table called comments with a name and email, the body attribute and a task id, basically this will refer to the tasks table in line 34. We have a title, a bulletin that tells whether it's done or not, the project id, and also the time stamps. These are valid for every single table. In the projects table, we have a name and a date. That tells us the expected date of the project being ended. Now, I'm taking a look at this and I'm thinking maybe I could add some more information into the project, for example, a list of clients or a description. I think a description block sounds good. So in order to change the projects table, the wrong approach is to go to the migrate folder and then choose the create projects migration and change it. This is not the way to go. Think of the migration files as immutable. So they shouldn't be changing at all over time. Once you run the migration, you shouldn't really go back unless something is really dangerous and you wanna roll back the changes before deploying everything into production. So be very careful about that. Instead, what you do is create a new migration that will change the projects table. I'm gonna step out of the editor a little bit and go to the terminal. You should type in the following instruction, rails generate or g for short and then migration. The migration name has a little trick. I'm going to show you what it is. So the objective is to add a description to the project staple. So I type in something like add_description_to_projects. The trick in this entire text is the project's name. Rails is smart enough to recognize the last word and if it is a table, then it is going to change that table with a specific field. So if I type in something like description:text, Rails will be smart enough to create a migration that changes the table in order to add that description. If I scroll down to the migrate folder, you will see the new file. And if I press Enter, you will see this add column with the table, the field and the type of the field. Remember, the magic trick is the last word, so everything after the last underscore should be smart enough to be a table name. And all of the fields you add next will be added into that specific table. That's the trick. Now in order to run these changes, you type in the rate db:migrate again. It will pick up on the last migration that was run, and run all subsequent migrations. And the result is the projects table will be changed in the way that it has one more column. This is something that works really well. I really like this feature a lot about Rails. However, there's one thing that you should do. Remember that this only changed the schema of the database, not the templates per se. So if you wanna change them in order to include this description, you go to Views, Projects, and then Form, in this particular instance, and replicate something in the terms of what's already there. In this case, I'll copy a field class div, then use the same label and text field to include the description. Oh, by the way, this shouldn't be text field at all, it should be text area. And then the description. Now if I choose to open a browser, let's go right there really quick. So let's type in localhost3000 and then /projects, you will see that there's no description at all yet. We're going to change that in just a second. Now let's go to the first project and you can see the description field right there. This was my first project ever, And if I choose to update the project, you will see that this will still turn out to be a failure, even though the project was successfully updated. There are a couple of tricks I should mention. Let's search for the last patch operation. After all, when we chose to edit a particular project and hit Save, the HTTP method that's being projected is patch, instead of post or pet or gleet. Patch is the method that resembles an update to an existing object. So, let's see, oh, there it is. So there's the patch method and you will pay very close attention to this line. It says, unpermitted parameter description. Why does this have to do with anything? Well first of all, you can see that the description is right there in the parameters hash along with all the remaining parameters, but when trying to update the project, you won't see it anywhere in the SQL query. So there's only a select query, but not an update query. For this we're gonna go to our editor, again. And go to the controllers, ProjectsController. Now, the reason behind this unpermitted parameter sentence, is due to this strong parameter's feature, available in Rails IV. I'm gonna go to the very end of the project, and you'll see this project_params method. This method is being used, for example, in the update method and also in the create method. When creating a new project you will need to choose a selection of the parameters from the parameters hash. The strong parameters gem was introduced to increase security. So that users wouldn't be able to introduce additional data and possibly compromise your application. So, in this specific method we're going to require the project hash inside and only allow the name and ends at attribute to be sent. The description is being left out, so we just add that description method in. This will allow the description parameter to be passed through and update the project accordingly. Now I'm gonna focus my attention on the server tab again and now I'm going to go to the browser, choose to edit again. Okay I just went back to retrieve what I had typed before and now I'm gonna choose to update the project. It seems that everything went okay, but this is tricky. We still need to double check on the server. Going there, you will see that the update query is there. Okay, awesome job. The description value is being updated, and notice how we don't have that unpermitted parameters thing anywhere. So the text is gone, that means that the description view was indeed accepted. So you've learned about two things now, how to add in a new migration with a command to add a column to one specific table. You've also learned a little bit more about how to adjust your application to reflect these changes, in specific, how to add in new fields to a controller so whitelist certain attributes. And now the last thing we should be doing is to update the templates which we've already done in the form only. We can choose to go, for example, to the show page and add in a description. If I add in a block quote, for example, like so, I can choose to print out that project's description, just like so. Now, if I go ahead and run this, just riddle the page for the project, you can see the block code with the description. I could add in the description but I could add more stuff of course. It really depends on the nature of our objectives. If you have something else you would like to add you just need to repeat the same process but with different data. If you wanna know all about migrations, check this link that I'll post in the description. This page is all about migrations. You can see the overview on the right about many different aspects of writing and creating migrations. So, all the way from creating a migration, to writing them with specific methods that you can use to manipulate the database are here. This is the best read to know everything about them.