advertisement

Print

How to Build Simple Console Apps with Ruby and ActiveRecord
Pages: 1, 2, 3, 4

Living Without script/generate

One thing that's great about working with Rails is that it's really easy to generate the boilerplate for your project, and you also have a well defined directory structure to start with. When writing standalone scripts, you'll need to do most of that stuff by hand. Luckily, it's not a particularly hard thing to do.



What follows are essentially several recipes for how to handle some of the tasks that the generators typically do for you. Feel free to skip by the ones you already are comfortable with.

Directory Structure

Before hooking everything up, it is worthwhile to set up a basic directory layout for your project. EarGTD's looks like this:

data/
  ear_gtd.db 
  test_ear_gtd.db
lib/
  ear_gtd.rb           
test/
  test_ear_gtd.rb

Rakefile
earGTD

For a simple app, this is about all we need. Usually when code is actually distributed, the scripts you can run from the command line will go in a folder called bin/, but we skipped that step for simplicity.

Otherwise, this structure is fairly common among Ruby projects: lib/ holds your library files, data/ holds any of the projects data files, test/ your unit tests, and your Rakefile will go in the top-level directory.

There's nothing mandating this project layout, if you want to put all your code in one big file, including your tests and data, Ruby will not stop you. Still, the conventions are handy, and many tools rely on them in order to function properly.

Connecting to a Database

When working with Rails, you normally stash your configuration information in config/database.yml, but when using ActiveRecord standalone, you have to do a tiny bit more leg work.

Below is an example of how to convert the YAML configuration to a Ruby call.

development:
  adapter: sqlite3
  database: db/my_database.sqlite3

becomes

ActiveRecord::Base.establish_connection(
  :adapter  => :sqlite3,
  :database => "db/my_database.sqlite3" 
)

As long as this code is defined before you try to work with your model data, ActiveRecord (AR) will work as normal.

Though it's not really necessary, it's also pretty trivial to emulate the rails style config file approach by just feeding a parsed YAML file to establish_connection.

Fun Ruby stuff: The YAML library

Let's say you have a YAML file called config/database.yml that looks like this:

adapter: sqlite3
database: data/ear_gtd.db

If you wanted to use this to configure AR, you'd just do:

require "yaml" 
ActiveRecord::Base.establish_connection(YAML.load_file("config/database.yml"))

The loaded YAML file actually just represents a Ruby Hash, so you can pass it directly to establish_connection.

Of course, it's often fine just to keep everything in Ruby and not worry about configuration files.

Database Schema Definition

For small standalone apps, you probably won't need the power of migrations. Still, it is nice to not have to write SQL when you can avoid it. This is where ActiveRecord::Schema comes in.

The relationships for EarGTD are extremely simple. Contexts and Projects both have many tasks. The code below is what I'm using for my schema definition:

  ActiveRecord::Schema.define do 
    create_table :tasks do |t|
      t.column :description, :string
      t.column :status, :string
      t.column :context_id, :integer
      t.column :project_id, :integer
    end

    create_table :contexts do |t|
      t.column :name, :string
    end

    create_table :projects do |t|
      t.column :name, :string
    end
  end

As you can see, aside from the explicit method call, the code you write is identical to that which would go in migrations.

Between ActiveRecord::Schema.define and ActiveRecord::Base.establish_connection, you have the tools you'll need to use AR outside of Rails. Model definitions work exactly the same way as they do in Rails, so there is nothing special to worry about there.

Pages: 1, 2, 3, 4

Next Pagearrow