Creating the Project Databases

When using SQLite, you aren’t forced to create the database, because a new database file is automatically created if one doesn’t exist; but it will come in handy when you try a different database engine. You also may see some messages like db/development.sqlite3 already exists. Don’t be afraid—this is an indication that an SQLite file was found. If you see that message, rest assured that your existing database was left untouched and no database file has been harmed.

Regardless of the database management system you select, you should notice that the databases you want to use are created. This is another case in which Rails removes some complexity from your mind and helps you focus on your application.

then you need to adjust your connection settings. If you’re having problems, make sure the database exists and that you’ve entered the correct username and password in the config/database.yml configuration file.

Creating the Article Model

Now that you can connect to the database, this section will explain how you create a model. Remember that models in Rails usually correspond to database table names. Because you want to model articles, let’s create a model named Article. By convention, model names are camel-cased singular and correspond to lowercased plural table names. So an Article model expects a table named articles; a Person model expects a table named people.

Like most things in Rails, models have their own generator script that makes it easier to get started. The generator automatically creates a new model file in the app/models directory and also creates a bunch of other files. Among these are a unit test (for testing your model’s functionality, as discussed in Chapter 16) and a database migration. A database migration contains instructions for modifying the database table and columns. Whenever you generate a new model, a migration is created along with it.

As you can see from the usage banner, the generator takes a model name as its argument and an optional list of fields. The model name may be given in camel-cased or snake-cased format, and options can be provided if you want to automatically populate the resulting migration with column information.

If you look at the lines that start with create, you see that the generator has created an Article model, an Article test, an articles fixture (which is a textual representation of table data you can use for testing), and a migration named 20191219235126_create_articles.rb. From that, your model is generated.

Creating a Database Table

You need to create a table in the database. You could do this with a database administration tool or even manually using SQL, but Rails provides a much more efficient facility for table creation and maintenance called a migration. It’s called a migration because it allows you to evolve, or migrate, your schema over time. (If you’re not familiar with databases, tables, and SQL, consult Appendix B for the basics.)

What’s the best part about migrations? You get to define your schema in pure Ruby. This is all part of the Rails philosophy that you should stick to one language when developing. It helps eliminate context switching and results in higher productivity.

As you can see from the output of the model generator, it created a new file in db/migrate called 20191219235126_create_articles.rb. As mentioned before, migrations are named with a numeric prefix, which is a number that represents the exact moment when the migration file was created. Because multiple developers can create migrations in a development team, this number helps uniquely identify this specific migration in a project.

In its initially generated form, the migration is a blank canvas. But before you go any further, let’s note a few important items. First, notice the instance method: change. In previous versions of Rails, there would be an up and down class method, but now Rails is smart enough to figure it out based on the modifications you make in this method. You can roll back without ever writing a method that explicitly drops the table. Pretty slick, isn’t it?

Let’s step through the code. First, you use the create_table method, giving it the name of the table you want to create. Inside the code block, the string, text, and datetime methods each create a column of the said type named after the parameter; for example, t.string :title creates a field named title with the type string. The timestamps method, in the t.timestamps call, is used to create a couple of fields called created_at and updated_at, which Rails sets to the date when the record is created and updated, respectively. (For a full description of the available method types you can create in your migrations, see https://api.rubyonrails.org/classes/ActiveRecord/Migration.html.)

On its own, this migration does nothing. Really, it’s just a plain old Ruby class. If you want it to do some work and create a table in the database for you, you need to run it. To run a migration, you use the built-in db:migrate Rails command that Rails provides.

Just as the output says, the migration created the articles table. If you try to run the migration again (go ahead, try it), nothing happens. That’s because Rails keeps track of all the migrations it runs in a database table, and in this case there’s nothing left to do. If for some reason you decide you need to roll back the migration, you can use the db:rollback task to roll back. Try it and you will notice that it dropped the articles table. Remember that we never wrote any code to drop the table, Rails just handled it for us. Imagine if you would have edited the database schema directly with a database management tool; if you wanted to roll back, you’d have to remember what it looked like before and exactly what you changed. This makes your life much easier. Okay, before we move on, don’t forget to run migrations again since we rolled back.

Generating a Controller

The controller generator also creates an empty directory in app/views called articles. This is where you place the templates for the articles controller.

Up and Running with Scaffolding

One of the most talked-about features that has given a lot of exposure to Rails is its scaffolding capabilities. Scaffolding allows you to create a boilerplate-style set of actions and templates that makes it easy to manipulate data for a specific model. You generate scaffolding using the scaffold generator. You’re probably getting used to generators by now. Rails makes heavy use of them because they help automate repetitive tasks and generally remove the chances for errors when creating new files. Unlike you probably would, the generator won’t ever forget how to name a file; nor will it make a typo when creating a class. Let’s use the scaffold generator now and solve the mystery of how this works.

You should see the results displayed in your browser, as shown in Figure 3-2.

Click the New Article link, and you’re taken to a screen where you can enter articles. Notice that the URL is http://localhost:3000/articles/new, which means you’re invoking the new action on the articles controller. Go ahead and add a few articles and generally play with the application. Figure 3-3 shows an example of an article entered on this screen.

Notice that every time you add an article, you’re redirected back to the show action, where you see the details of the article you just created. You can click “Back” to go the index action, where you see all of your articles listed. You can edit them, delete them, or create new ones. You’ve got to admit, Rails gives you a lot of functionality for free.

Speed is the key benefit here. The scaffold generator allows you to quickly get something running, which is a great way to test your assumptions.

Adding More Fields

Now that you can see the model represented in the browser, let’s add some more fields to make it a little more interesting. Whenever you need to add or modify database fields, you should do so using a migration. In this case, let’s add the excerpt and location fields to the articles table.

Looking at the add_column method, the first argument is the table name (articles), the second is the field name, and the third is the field type. Remember that the change method knows how to migrate up or down, so if in the unlikely event you want to remove these columns, Rails will know how.

If all goes according to plan, the articles table now has two new fields. You could edit the view templates in the app/views/articles folder to add form elements for the new fields, but instead let’s call the generator again (you’ll learn about views in Chapter 7):

Press Y when asked if you want to overwrite some files, and you’re finished, as you can see in Figure 3-4.

This exposes one of the issues of this type of scaffolding: when you generate new versions of the scaffold files, you run the risk of overwriting custom changes you may have made. We’re doing it this way as an illustration, but you wouldn’t normally do this.

Adding Validations

You may wonder what happens if you try to save a new article without giving it any information. Try doing that: Rails doesn’t care. Actually, it’s the Article model that doesn’t care. This is because in Rails, the rules for data integrity (such as required fields) are the responsibility of the model.

Save the file, and try creating an empty article again. Instead of saving the record, Rails displays a formatted error message, as shown in Figure 3-5.

If you’ve done any web development before, you know that validating fields is a major nuisance. Thankfully, Rails makes it easy.

Chapter 6 goes through all the specifics of model validations. For now, you’re using only the most primitive methods of protecting your data. It shouldn’t surprise you that Active Record is capable of much more involved validations, such as making sure a numeric value is entered, validating that data are in the correct format using regular expressions, and ensuring unique values, among other checks.

Generated Files

As you did in this chapter, after you’ve generated scaffolding, if you change your model, you have to regenerate it if you want your application to follow suit. Most of the time, however, you make the changes by hand and have a variation of the default scaffold.

It’s important to realize why scaffolding exists and to be aware of its limitations. As you’ve just seen, scaffolding helps when you need to get something running quickly to test your assumptions. It doesn’t take you very far in the real world, and eventually you end up replacing most (if not all) of it.

Explore the generated code and see if you can figure out how it hangs together. Don’t worry if you can’t understand all of it—the chapters that follow will discuss it in depth. With everything you know about Rails already, you should be able to piece together most of it.

Try changing a few things to see what happens. If you inadvertently break something, you can always run the scaffolding generator again to revert to the original. Can you see how the views in app/views/articles are related to the actions? What about the response messages, like Article was successfully created? What happens when you change them? See if you can find where the error messages for failed validations are rendered. If you remove the message, does the record still get saved? You can learn a lot by exploring, so take as much time as you need.