There were two final day workshops featured at RubyConf. Naturally, I wanted to attend both.

1. Hands-on Rails with DHH
2. Continuations Demystified with Jim Weirich and Chad Fowler

Although I had originally decided to go to the Continuations workshop, DHH announced that he would be showing the new features in Rails 1.0.

Rails 1.0 addresses several problems with previous releases. We shall have to see how well these actually work when put into practice.

db/schema.rb

Finally, we can specify the DB schema in ruby. No more messing about with DB interfaces. Note it does not cater for foreign keys, only indexes. It does allow constraints to be specified.

ActiveRecord::Schema.define() do
  create_table "comments", :force => true do |t|
    t.column "body", :text
    t.column "heading", :string, :limit => 45, :default => "Moo", :null => false
    t.column "post_id", :integer
    t.column "author_id", :integer
  end

  create_table "posts", :force => true do |t|
    t.column "name", :string, :size => 45, :null => false
  end

  create_table "authors", :force => true do |t|
    t.column "name", :string, :null => false
  end

  create_table, :id => false do |t|
    t.column "post_id", :integer
    t.column "comment_id", :integer
  end

  add_index "posts", "name"
end

There are a couple of rake tasks which allow you to fetch and dump your DB schema from the DB. These are highly destructive.

rake db_schema_dump will fetch the DB schema from the DB and overwrite your db/schema.rb with no warning

rake db_schema_import will overwrite your DB with db/schema.rb and drop all your existing tables and data. This will wipe out your existing data without warning. There is also no transaction support. If your import task fails for any reason, then your DB is in an unknown state. Most likely you no longer have any tables.

Migrations

script/generate migration add_comment_author will create db/migrate/1_add_comment_author.rb

This allows you to set up a series of events to alter your DB (either just data or schema, or both). It is possible to migrate up and down.

class AddCommentAuthor < ActiveRecord::Migration
  def self.up
    add_column :posts, :author_name, :string
    Post.find(:all).each { |post| post.author_name = "X" }
  end

  def self.down
    remove_column :posts, :author_name
  end
end

Rails::Initializer

Whenever a new version of Rails was released, our scripts, environment.rb, etc. of existing applications were not updated. This is being addressed by Rails::Initializer. Now most files which are generated by Rails are stubs pointing into the gems.

script/* are now calling the gems eg.

script/server

#!/usr/bin/ruby1.8
require File.dirname(__FILE__) + '/../config/boot'
require 'commands/server'

environment.rb has been reconfigured: (after removing the comments, it looks like this)

require File.join(File.dirname(__FILE__), 'boot')
Rails::Initializer.run do |config|
end

boot.rb is a bootstrapper to set load paths.

Session storage in the DB is now improved. Intended to be used with first setting up the rails project. Add a configuration option to environment.rb:

  # Use the database for sessions instead of the file system
  # (create the session table with 'rake create_sessions_table')
  config.action_controller.session_store = :active_record_store

then run rake create_sessions_table

DHH points out that all this is, is a nicer interface to older calls. So all existing environment.rbs should still work. We'll see how abackwardly compatible it actually is.

Rake

The Rakefile has been cut down and modularized. You can add new tasks to lib/tasks

Improved FCGI support

Inside script/process there are three hopefully useful files.

• spawner - this will spawn your FCGI processes
• reaper - this will reload, restart, kill you FCGI processes
• spinner - this will continually call spawner. Not intended for use unless necessary.

haproxy can be used to trick Apache into thinking there is only one fcgi process.

SwitchTower

switchtower --apply-to myrails_app will create the files:

• config/deploy.rb
• lib/tasks/switchtower.rake

This allows you to write any release things into switchtower.rake eg. hooks into reaper or migration. See manuals.rubyonrails.com for more details

Plugins

Plugins allow you to extend Rails. For example, to add acts_as_something to your AR objects, you would create the directory: /vendor/plugins/acts_as_something/lib

• init.rb - is called in environment.rb
• acts_as_taggable.rb - contains your class

Prototype 1.4 and Scriptaculous 1.5

Ajax has been improved to allow you to access Ruby objects in Javascript.

Binding Gems and Edge

In previous versions of Rails, we could use any set of gems by explicitly requiring them. Now that the scripts are stubs pointing at the gems, there is a new mechanism to set the rails version you want to use.

rake freeze_gems This will copy the current rails gems into vendor/

rake unfreeze_rails This will remove the gems from vendor/

rake freeze_edge This will pull the latest SVN Edge Rails in to vendor/.

Per-action Session Management

Sessions are accessed whenever someone access the site, whether or not it is necessary. If you are using DB sessions, then there is additional unnecessary overhead. Now we can specify actions which do not need to access sessions information.

class WeblogController < ApplicationController
  session :off # no sessions added for any actions
  session :off, :only => :feed # sessions off for feed

end

DHH announced that Rails Core would be releasing the release candidate on Sunday afternoon. I believe it is now available as 0.14.0.