Juan Lupión wrote in to inform me that he’s also translating my Living on the Edge (of Rails) series of blog posts to Español. Thanks Juan! (0)

Living on the edge (of Rails) #21

It’s another slow week (just 2 changes of note imho) after the release of the 1st Release Candidate (RC1) of Rails 2.1. Follow that link for installation instructions - though if you’re reading this blog post you probably don’t care! (because you’re, you know, “living on the edge”). Cheesiness aside, be sure to report any bugs you may encounter when upgrading to 2.1 RC1 or edge at the Rails bug tracker - it is an RC so any bug reports would be very welcome and useful!

This week’s report covers changes from 12th May 2008 to 18th May 2008 (the day the corresponding Rails Envy podcast was recorded).

caches_action can has conditionals

caches_action now takes an :if option (just like caches_page does). For example:

caches_action :index, :if => Proc.new { |c| !c.request.format.json? }

This little enhancement is courtesy of José Valim.

Related changeset: http://github.com/rails/rails/commit/7708650f73ddb4db300ea2059c60c1d907a4384e

Bugfix: :select option is now scanned in ActiveRecord finders to ensure needed tables are included in generated SQL

Post.find(:all, :include => :author, :select => 'posts.*, authors.id as "author_id"', :limit => 2)

Would generate an SQL statement like this:

SELECT posts.*, authors.id as "author_id" FROM "posts" LIMIT 2

Notice how the authors table is not joined. This oversight is now fixed.

Thanks go to John Devine for this bugfix.

Related changeset: http://github.com/rails/rails/commit/b28b54cab090bed8f099ef375b419a8f92390dd4

As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series. Also, if anyone has any recommendations of (non-ruby-related) things to do in Portland, do let me know!

Deploying with Capistrano via a gateway - some notes

Some notes on setting up a gateway server for deploying via Capistrano that I couldn’t find at the source.

  • You can specify the user you want to use to login to your gateway server like so: set :gateway, 'deploy@deploy.example.com'. This logs in to your gateway server as the “deploy” user.
  • You can specify an alternate SSH port for both your gateway and your deployment servers. E.g. setting ssh_options[:port] = 11111 will make Capistrano SSH to your gateway server with on port 11111. For your actual application (and web and database) servers, you can specify the SSH port like so:
    set :gateway, 'deploy@deploy.example.com'
    role :app, '192.168.1.113:22222'
    role :web, '192.168.1.113:22222'
    role :db,  '192.168.1.113:22222', :primary => true
  • If you’re using public key authentication, you should put the public keys of your users (those who be deploying your app) on the gateway server and on the actual servers. I thought Capistrano would use the key of the “deploy” user but nope.

Living on the edge (of Rails) #20 - script/dbconsole and flash.now now test-able

This week’s report covers changes from 5th May 2008 to 11th May 2008 (the day the corresponding Rails Envy podcast was recorded).

script/dbconsole

A script/dbconsole script has been added that allows you to connect to your database using its console client.

If you needed to connect to your production MySQL database (you better know what you are doing!), for example, you can run RAILS_ENV=production script/dbconsole or simply script/dbconsole production (thanks to Ryan Bates for pointing this out!) and it will login to your database server using the command line MySQL client. This also works with the PostgreSQL and SQLite databases.

To use this script in your Rails app, remember to run rake rails:update:scripts after updating to edge Rails.

This nice little enhancement courtesy of Steve Purcell, who originally had a similar database console plugin.

Related changeset: http://github.com/rails/rails/commit/4a07103687084496b773e18a03b1f2f5e686f7ad

flash.now is now accessible in tests

This is something that many of us Rails developers have probably come across when writing tests for flash messages being set with flash.now, myself included. Basically, you couldn’t test the contents of your flash.now because they were always being emptied before your test could get to them.

# In your controller:
flash.now[:notice] = 'You gotta be kidding me!'

# In your test:
assert_equal 'You gotta be kidding me!', flash.now[:notice]
# FAILS because flash.now[:notice] is nil

Andreas Neuhaus took a good look at how it works and figured out how to make testing flash.now work without resorting to assert_selects.

Related changeset: http://github.com/rails/rails/commit/74eed6290e63111d1aad2b181692a84f4f040aea

There isn’t much else of note so far but if you’d like to know every gritty detail, you’d probably want to peruse the Rails commit logs. As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series.

Living on the edge (of Rails) #19 - change_table for migrations and more

This week’s report covers changes from 29 April 2008 to 4th May 2008 (the day the corresponding Rails Envy podcast was recorded).

change_table for ActiveRecord migrations

Thanks to Jeff Dean, who also blogged about the new change_table feature in ActiveRecord migrations, you can now change a table with a block like so:

change_table :videos do |t|
  t.add_timestamps
  t.add_belongs_to :goat
  t.add_string :name, :email, :limit => 20
  t.remove_column :name, :email # takes multiple arguments
  t.rename :new_name
  t.string :new_string_column # executes against the renamed table name
end

Some key things to note:

  • add_XXX would add a new column for you, e.g. add_string would add a new string field.
  • Of course, add_timestamps would add the magic created_at and updated_at datetime fields.
  • remove_column now takes multiple arguments.
  • rename would rename the table.

Very nice, DRY enhancement, props to Jeff Dean once again.

Related changeset: http://github.com/rails/rails/commit/96980bd561d79824b6cb6efbcbecdcbf8785d452

ActiveRecord::Base.create takes a block like ActiveRecord::Base.new

Yup now you can also create ActiveRecord objects with a block argument just like you could for ActiveRecord::Base.new:

@person = Person.create(params[:person]) do |p|
  p.name = 'Konata Izumi'
  p.age = 17
end

Credit goes to Adam Meehan for this patch.

Related changeset: http://github.com/rails/rails/commit/dd120ede53eaf71dee76894998a81626b7a689fc

Bugfix: change_column should be able to use :null => true on a field that
formerly had false

You can now use change_column in your migrations to alter a column as nullable if it was previously NOT NULL.

This bugfix is courtesy of Nate Wiger.

Related changeset: http://github.com/rails/rails/commit/10ef65a3b054270ed3d458ec8eb7c2b9a3e638f7

As always, let me know of any suggestions or how I can improve the Living on the Edge (of Rails) series.