Comprehensive Rails File System Guide, Part 2 of 2
In this lesson we'll walk through the second part of the Rails file system, starting with the db directory.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license

In the last part, we saw the app and config directories in detail. In this part, let's start with the db directory.

db directory

This directory contains the following files:

development.sqlite3 - You will do nothing with this file.

production.sqlite3 - Like the development database, you should not be doing anything in this file either.

schema.rb - This is a file that you will use often, but you should never edit it directly. You can make changes to this file only through migration, and not by a direct edit to avoid problems later on. You will mostly use this file to view your database columns, data types and any other similar information. In this sense, this file acts as a great point of reference.

seeds.rb - This is the place where you will put your test data.

lib directory

Again, most people don't use this directory much. It has two folders - assets and tasks. Out of the two, you will do nothing with assets folder. On the other hand, the tasks folder is an important one as this is where you can place custom rake tests that can be called at the command line. Using these rake tests, you can create custom behavior, and this is why you are likely to use it quite a lot.

An example of such a behavior is let's say I'm connected to an external API and I want to bring in data from that API to my system every night at 12 AM, so that my local database is up to date. To do this, I will place a custom test file here and run a heroku or cron job to schedule it at the time I want.

By default, the tasks directory contains a file called .keep. The reason is github, a popular version control system, ignores empty directories and folders. Hence, this file exists to maintain the same directory structure on the repository too.

log directory

You can find all logs here. Personally, I don't use this directory so much because I don't like the way Rails creates logs. Instead, I connect with third-party software like appsignal to check my logs.

That said, you can use this directory if you feel comfortable with the log format generated by Rails. You can find all the information you want in the file development.log.

public directory

In this directory, you can keep files such as the error pages 404.html and robots.txt. Out of these, the robots file is important as it can determine how search engines index and access your files.

test directory

This is where all the automated tests will get placed. I won't go too much into this because I prefer to use tools like RSpec for unit testing.

tmp directory

This directory contains all your temporary files, and you will probably never use this directory at all.

vendor directory

This directory contains a folder called assets that in turn contains two folders called javascripts and stylesheets. If you notice, it is similar to the assets folder in your app directory, and there is a reason for it. In the earlier versions, this directory had the assets folder and it continues to exist in later versions too, otherwise legacy applications will fail.

Also, this directory will come handy when you want to use third-party service or a client side MVC, as you need a place to store and access those javascript and CSS files.

Other than these directories, you have the following files:

-gitignore - This file is used to store your passwords or any other information that you don't want to load into version control systems like github.

config.ru - You will do nothing in this file, so you don't have to worry about it.

Gemfile - This is a file that you would use a lot. It contains all the gems that are included in the application. Gems are nothing but outside libraries that you use to bring in certain functionality to your application. Don't feel overwhelmed by these gems because they are essentially just Ruby code that bring in certain methods for your application. It saves time and effort, more than anything else.

If you don't want any gems, you can manually do all the code yourself, but you would just be reinventing the wheel.

Also, you can add the gems individually to each file, though it's not considered good programming practice.

Gemfile.lock - This is another file that you should never edit directly. It contains gems nested within other gems like for example

sass-rails (5.0.3)

 railties (>=4.0.0, <5.0)

 sass (~> 3.1)

 sprockets (>=2.8, <4.0)

 sprockets-rails (>=2.0, <4.0)

 tilt (~>1.1)

Rakefile - This is another file that you don't have to open at all.

README.md - It contains information that you typically want the user to know like how to get the application up and running, how to install it on the local machine and any other information that you think would help a person to better use your application.

With this, we are done with the file system.