So, after sitting down with the customer and doing some preliminary analy- sis, we’re ready to start using a computer for development! We’ll be working from our original three diagrams, but the chances are pretty good that we’ll be throwing them away fairly quickly—they’ll become outdated as we gather feed- back. Interestingly, that’s why we didn’t spend too long on them—it’s easier to throw something away if you didn’t spend a long time creating it.
In the chapters that follow, we’ll start developing the application based on our current understanding. However, before we turn that page, we have to answer just one more question. What should we do first?
I like to work with the customer so we can jointly agree on priorities. In this case, I’d point out to her that it’s hard to develop anything else until we have some basic products defined in the system, so I’d suggest spending a couple of hours getting the initial version of the product maintenance functionality up and running. And, of course, she’d agree.
• creating a new application • configuring the database • creating models and controllers • running database migrations • using static and dynamic scaffolds • performing validation and error reporting • working with views and helpers
Chapter 6
Task A: Product Maintenance
Our first development task is to create the web interface that lets us maintain our product information—create new products, edit existing products, delete unwanted ones, and so on. We’ll develop this application in small iterations, wheresmallmeans “measured in minutes.” Let’s get started.
6.1
Iteration A1: Get Something Running
Perhaps surprisingly, we should get the first iteration of this working in almost no time. We’ll start off by creating a new Rails application. This is where we’ll be doing all our work. Next, we’ll create a database to hold our information (in fact we’ll create three databases). Once that groundwork is in place, we’ll
• configure our Rails application to point to our database(s), • create the table to hold the product information, and
• have Rails generate the initial version of our product maintenance appli- cation for us.
Create a Rails Application
Back on page43we saw how to create a new Rails application. Go to a com- mand prompt, and typerails followed by the name of our project. In this case, our project is calleddepot, so type
work> rails depot
We see a bunch of output scroll by. When it has finished, we find that a new directory,depot, has been created. That’s where we’ll be doing our work. work> cd depot
depot> ls -p
README components/ doc/ public/ tmp/
Rakefile config/ lib/ script/ vendor/
Create the Database
For this application, we’ll use the open source MySQL database server (which you’ll need too if you’re following along with the code). I’m using MySQL ver- sion 5 here. If you’re using a different database server, the commands you’ll need to create the database and grant permissions will be different.
We also have to talk briefly about database users and passwords. When you initially install MySQL, it comes with a user calledroot. In this book, we’ll use the root user to access the database in development and test mode. If you’re developing and testing on a dedicated machine, this works fine. In production, or if you’re running a database that’s accessible to others, you’ll definitely want to create special user accounts and passwords to prevent other people accessing your data. Let me repeat that: ALWAYS CHANGE THE USER NAME AND PASSWORD OF THE PRODUCTION DATABASE BEFORE DEPLOYING. See your database documentation for details.
What shall we call our database? Well, we could call it anything (Walter is a nice name). However, as with most of Rails, there’s a convention. We called our application “depot,” so let’s call our development databasedepot_development. We’ll use themysqladmin command-line client to create our databases, but if you’re more comfortable with tools such asphpmyadminorCocoaMySQL, go for it.
depot> mysqladmin -u root create depot_development
Now you get to experience one of the benefits of going with the flow.1 If you’re using MySQL and if you’ve created a development database with the suggested name, you can now skip forward to Section6.1,Testing Your Configuration, on page71.
Configure the Application
In many simple scripting-language web applications, the information on how to connect to the database is embedded directly into the code—you might find a call to some connect method, passing in host and database names, along with a user name and password. This is dangerous, because password infor- mation sits in a file in a web-accessible directory. A small server configuration error could expose your password to the world.
The approach of embedding connection information into code is also inflexible. One minute you might be using the development database as you hack away. Next you might need to run the same code against the test database. Even- tually, you’ll want to deploy it into production. Every time you switch target databases, you have to edit the connection call. There’s a rule of programming 1. Or,convention over configuration,as Rails folks say (ad nauseam)
that says you’ll mistype the password only when switching the application into production.
Smart developers keep the connection information out of the code. Sometimes you might want to use some kind of repository to store it all (Java developers often use JNDI to look up connection parameters). That’s a bit heavy for the average web application that we’ll write, so Rails simply uses a flat file. You’ll find it inconfig/database.yml.2 # ... some comments ... development: Ê adapter: mysql Ë database: depot_development Ì username: root password: Í host: localhost
database.ymlcontains information on database connections. It contains three sections, one each for the development, test, and production databases. If you’re going with the flow and using MySQL with root as the user name, yourdatabase.ymlfile is probably ready to use—you won’t need to make any changes. However, if you’ve decided to rebel and use a different configuration, you might need to edit this file. Just open it in your favorite text editor, and edit any fields that need changing. The numbers in the list that follows correspond to the numbers next to the source listing.
Ê The adapter section tells Rails what kind of database you’re using (it’s
calledadapter because Rails uses this information to adapt to the pecu- liarities of the database). We’re using MySQL, so the adapter name is mysql. A full list of different adapter types is given in Section17.4,Con- necting to the Database, on page 290. If you’re using a database other than MySQL, you’ll need to consult this table, because each database adapter has different sets of parameters indatabase.yml. The parameters that follow here are for MySQL.
Ë Thedatabaseparameter gives the name of the database. (Remember, we
created our depot_development database using mysqladmin back on the preceding page.)
Ì The username and password parameters let your application log in to
the database. We’re using the userrootwith no password. You’ll need to change these fields if you’ve set up your database differently.
2. The .ymlpart of the name stands forYAML, or YAML Ain’t a Markup Language. It’s a simple way of storing structured information in flat files (and it isn’t XML). Recent Ruby releases include built-in YAML support.
Selecting a Different Database
You tell Rails which database adapter to use by changing values in the database.ymlfile in theconfigdirectory. Clearly, you can first create your appli- cation and then edit this file to use the correct adapter.
However, if you know that you’ll be using a database other than MySQL, you can save yourself some effort by telling Rails when you create the application. work> rails depot --database=sqlite3
The command rails --helpgives the list of available options. Remember that you’ll need the appropriate Ruby libraries for the database you select.
If you leave the user name blank, MySQLmight connect to the database using your login name. This is convenient, because it means that dif- ferent developers will each use their own user names when connecting. However, we’ve heard that with some combinations of MySQL, database drivers, and operating systems, leaving these fields blank makes Rails try to connect to the database as the root user. Should you get an error such as “Access denied for user ’root’@’localhost.localdomain’,” put an explicit user name and password in these two fields.
Í The host parameter tells Rails what machine your database is running
on. Most developers run a local copy of MySQL on their own machine, so the default oflocalhostis fine.
Remember—if you’re just getting started and you’re happy to use the Rails defaults, you shouldn’t have to worry about all these configuration details.
Testing Your Configuration
Before you go too much further, we should probably test your configuration so far—we can check that Rails can connect to your database and that it has the access rights it needs to be able to create tables. From your application’s top-level directory, type the following magic incantation at a command prompt. (It’s magic, because we don’t really need to know what it’s doing quite yet. We’ll find out later.)
depot> rake db:migrate
One of two things will happen. Either you’ll get a single line echoed back (say- ing something like “in (/Users/dave/work/depot)”), or you’ll get an error of some sort. The error means that Rails can’t work with your database. If you do see an error, here are some things to try.
• Check the name you gave for the database in the development: section of database.yml. It should be the same as the name of the database you created (usingmysqladminor some other database administration tool). • Check that the user name and password indatabase.yml match the one
you created on page69.
• Check that your database server is running.
• Check that you can connect to it from the command line. If using MySQL, run the following command.
depot> mysql -u root depot_development mysql>
• If you can connect from the command line, can you create a dummy table? (This tests that the database user has sufficient access rights to the database.)
mysql> create table dummy(i int); mysql> drop table dummy;
• If you can create tables from the command line butrake db:migratefails, double-check the database.yml file. If there are socket: directives in the file, try commenting them out by putting a hash character (#) in front of each.
• If you see an error saying “No such file or directory...” and the filename in the error ismysql.sock, your Ruby MySQL libraries can’t find your MySQL database. This might happen if you installed the libraries before you installed the database, or if you installed the libraries using a binary distribution, and that distribution made the wrong assumption about the location of the MySQL socket file. To fix this, the best idea is to rein- stall your Ruby MySQL libraries. If this isn’t an option, add asocket:line to yourdatabase.ymlfile containing the correct path to the MySQL socket on your system. development: adapter: mysql database: depot_development username: root password: host: localhost socket: /var/lib/mysql/mysql.sock
• If you get the error “Mysql not loaded,” it means you’re running an old version of the Ruby Mysql library. Rails needs at least version 2.5. • Some readers also report getting the error message “Client does not
support authentication protocol requested by server; consider upgrad- ing MySQL client.” This incompatibility between the installed version of
MySQL and the libraries used to access it can be resolved by following the instructions at http://dev.mysql.com/doc/mysql/en/old-client.html and issu-
ing a MySQL command such asset password for ’some_user’@’some_host’ = OLD_PASSWORD(’newpwd’);.
• If you’re using MySQL under Cygwin on Windows, you may have prob- lems if you specify a host oflocalhost. Try using127.0.0.1instead.
• You may have problems if you’re using the pure-Ruby MySQL library (as opposed to the more performant C library). Solutions for various operat- ing systems are available on the Rails wiki.3
• Finally, you might have problems in the format of the database.ymlfile. The YAML library that reads this file is strangely sensitive to tab charac- ters. If your file contains tab characters, you’ll have problems. (And you thought you’d chosen Ruby over Python because you didn’t like Python’s significant whitespace, eh?)
If all this sounds scary, don’t worry. In reality, database connections work like a charm most of the time. And once you’ve got Rails talking to the database, you don’t have to worry about it again.
Create the Products Model and Table
Back in Figure 5.3, on page 66, we sketched out the basic content of the products table. Now let’s turn that into reality. We need to create a database table and a Railsmodelthat lets our application use that table.
At this point, we have a decision to make. How do we specify the structure of our database table? Should we use low-level Data Definition Language (DDL) statements (create tableand friends)? Or is there a higher-level way, one that makes it easier to change the schema over time? Of course there is! In fact, there are a number of alternatives.
Many people like using interactive tools to create and maintain schemas. The phpMyAdmin tool, for example, lets you maintain a MySQL database using web forms. At first sight this approach to database maintenance is attractive— after all, what’s better than just typing some stuff into a form and having the tool do all of the work? However, this convenience comes at a price: the history of the changes you’ve made is lost, and all your changes are effectively irre- versible. It also makes it hard for you to deploy your application: you have to remember to make the same changes to both your development and produc- tion databases (and we all know that if you’re going to fat finger something, it’ll be when you’re editing the production schema).
Fortunately, Rails offers a middle ground. With Rails, you can definedatabase
migrations. Each migration represents a change you want to make to the
database, expressed in a source file in database-independent terms. These changes can update both the database schema and the data in the database tables. You apply these migrations to update your database, and you can unapply them to roll your database back. We have a whole chapter on migra- tions starting on page262, so for now, we’ll just use them without too much more comment.
Just how do we create these migrations? Well, when you think about it, we normally want to create a database table at the same time as we create a Rails model that wraps it. So Rails has a neat shortcut. When you use the generator to create a new model, Rails automatically creates a migration that you can use to create the corresponding table. (As we’ll see later, Rails also makes it easy to create just the migrations.)
So, let’s go ahead and create the model and the migration for our products table. Note that on the command line that follows, we use the singular form,
product.In Rails, a model is automatically mapped to a database table whose name mapping
֒→page240 name is the plural form of the model’s class. In our case, we asked for a model
called Product, so Rails associated it with the table called products. (And how will it find that table? We told it where to look when we set up thedevelopment entry inconfig/database.yml.)
depot> ruby script/generate model product exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/product.rb create test/unit/product_test.rb create test/fixtures/products.yml create db/migrate create db/migrate/001_create_products.rb
The generator creates a bunch of files. The two we’re interested in are the model itself,product.rb, and the migration001_create_products.rb. Let’s look at that migration file first.
The migration has a sequence number prefix (001), a name (create_products), and the file extension (.rb, because it’s a Ruby program). Let’s add the code to this file that creates the table in the database. Go to thedb/migratedirectory and open the file001_create_products.rb. You’ll see two Ruby methods.
class CreateProducts < ActiveRecord::Migration def self.up
create_table :products do |t| # t.column :name, :string
end end
def self.down
drop_table :products end
end
Theup method is used when applying the migration to the database. This is where the code that defines our table goes. Thedownmethod undoes the effect of theupmethod: it is run when reverting the database to a previous version. You can see that Rails has already added the code that will create and drop the table in these two methods. Our job now is to tell it the columns we want. Edit the file so that it looks like the following.
Download depot_a/db/migrate/001_create_products.rb
class CreateProducts < ActiveRecord::Migration def self.up
create_table :products do |t| t.column :title, :string t.column :description, :text t.column :image_url, :string end
end
def self.down
drop_table :products end
end
The file looks fairly similar to raw DDL that we might feed to our database directly, but it’s actually Ruby code. Where we might type create table to