If you've ever read any beginner's articles about Ruby on Rails, you'll know that quite a bit of thought has been put into the code base that makes up the Rails framework. Over time, many of the internals have been rewritten, which has improved their speed and efficiency and allowed the implementation of additional features, but the original architecture remains largely unchanged. In this article, I'll help beginners take that next step by examining the inner workings of Rails. If you're yet to experiment with Rails, I'd recommend you download a free preview of my new book, Simply Rails 2, from which this information is excerpted. The chapter presented here gives a surface-level tour of the Ruby on Rails framework, and prepares the reader for building a digg-clone, which we've named (somewhat cheekily) Shovell. If you need installation and other setup instructions, download the sample PDF, which contains chapters 1 to 4. Three Environments Rails encourages the use of a different environment for each of the stages in an application's life cycle -- development, testing, and production. If you've been developing web applications for a while, this is probably how you operate anyway; Rails just formalizes these environments. development In the development environment, changes to an application's source code are immediately visible; all we need to do is reload the corresponding page in a web browser. Speed is not a critical factor in this environment. Instead, the focus is on providing the developer with as much insight as possible into the components responsible for displaying each page. When an error occurs in the development environment, we are able to tell at a glance which line of code is responsible for the error, and how that particular line was invoked. This capability is provided by the stack trace (a comprehensive list of all the method calls leading up to the error), which is displayed when an unexpected error occurs. test In testing, we usually refresh the database with a baseline of dummy data each time a test is repeated: this step ensures that the results of the tests are consistent, and that behavior is reproducible. Unit and functional testing procedures are fully automated in Rails. When we test a Rails application, we don't view it using a traditional web browser. Instead, tests are invoked from the command line, and can be run as background processes. The testing environment provides a dedicated space in which these processes can operate. production By the time your application finally goes live, it should be sufficiently tested that all -- or at least most -- of the bugs have been eliminated. As a result, updates to the code base should be infrequent, which means that the production environments can be optimized to focus on performance. Tasks such as writing extensive logs for debugging purposes should be unnecessary at this stage. Besides, if an error does occur, you don't want to scare your visitors away with a cryptic stack trace; that's best kept for the development environment. As the requirements of each of the three environments are quite different, Rails stores the data for each environment in entirely separate databases. So at any given time, you might have: * live data with which real users are interacting in the production environment * a partial copy of this live data that you're using to debug an error or develop new features in the development environment * a set of testing data that's constantly being reloaded into the testing environment Let's look at how we can configure our database for each of these environments. Database Configuration Configuring the database for a Rails application is incredibly easy. All of the critical information is contained in just one file. We'll take a close look at this database configuration file, then create some databases for our application to use. The Database Configuration File The separation of environments is reflected in the Rails database configuration file database.yml. We saw a sample of this file back in Chapter 1, and in fact we created our very own configuration file in Chapter 2, when we used the rails command. Go take a look -- it lives in the config subdirectory of our Shovell application. With the comments removed, the file should look like this: Example 4.1. 01-database.yml development: adapter: sqlite3 database: db/development.sqlite3 timeout: 5000 test: adapter: sqlite3 database: db/test.sqlite3 timeout: 5000 production: adapter: sqlite3 database: db/production.sqlite3 timeout: 5000 This file lists the minimum amount of information we need in order to connect to the database server for each of our environments (development, test, and production). With the default setup of SQLite that we installed in Chapter 2, every environment is allocated its own physically separate database file, which calls the db subdirectory home. The parameter database sets the name of the database that is to be used in each environment. As the configuration file suggests, Rails can support multiple databases (and even different types of database engines, such as MySQL for production and SQLite for development) in parallel. Note that we're actually talking about different databases here, not just different tables -- each database can host an arbitrary number of different tables in parallel.