Ryan's Scraps

Not to be outdone by his neighbor to the west, Kenji Kobayashi is maintaining japanese translations of the What’s New in Edge Rails series. Thanks for spreading the news, Kenji!

tags: ruby, rubyonrails

Rails migrations are a somewhat contentious bunch. On one hand they provide a consistent way of provisioning your database, and on the other hand they like to conflict with each other if there’s a heavy stream of development due to a simplistic naming convention. Just in is a change that will name your migrations based on a more unique UTC-based timestamp instead of just a sequential ordering.

When you go to create your next migration you’ll see something like this:

1
2

> script/generate migration one
      create  db/migrate/20080402122512_one.rb

Instead of the migration file being named 001_one.rb it now has a more unique prefix that will less likely conflict with another migration somebody else happened to check-in around the same time.

Update: When you do an svn update and get new migrations, even if they have a timestamp previous to a migration you’ve already added and run in your own environment, rake db:migrate will intelligently apply all migrations that have not yet run. This eliminates the interleaved migrations issue that existed on the first rev of this feature (see comments).

Another change that accompanies this functionality is the addition of rake db:migrate:up and rake db:migrate:down tasks, which will let you run the up and down operations of an individual migration (that may have been added on an svn merge or update):

1
2
3
4
5

> rake db:migrate:up VERSION=20080402122523
== 20080402122523 Two: migrating ==============================================
-- create_table(:two)
   -> 0.0122s
== 20080402122523 Two: migrated (0.0124s) =====================================

This functionality was previously available as the enhanced migrations plugin, so if you’re on an older version of Rails you can still make your migrations less whiny.

tags: ruby, rubyonrails

Rails plugins are great for many reasons, one being that they provide extra functionality without being an external dependency – they’re packaged right there with your application. Until recently, there was no way do programmatically define a Rails applications’ external gem dependencies and we were left with rolling our own gem dependency solutions.

That all changes with a nice way to define, and tie, gem dependencies to our Rails apps. In our environment.rb we have the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Rails::Initializer.run do |config| 

  # Require the latest version of haml
  config.gem "haml"

  # Require a specific version of chronic
  config.gem "chronic", :version => '0.2.3'

  # Require a gem from a non-standard repo
  config.gem "hpricot", :source => "http://code.whytheluckystiff.net"

  # Require a gem that needs to require a file different than the gem's name
  # I.e. if you normally load the gem with require 'aws/s3' instead of
  # require 'aws-s3' then you would need to specify the :lib option
  config.gem "aws-s3", :lib => "aws/s3" 
end 

So great – when your app loads up it will automatically find and require each of the gems you’ve listed. But what if you’re on a system that doesn’t have all of these gems installed, or you’ve just deployed to a fresh environment? There’s now a rake task that will install all the referenced config.gems on your target system:

rake gems:install

Before running this you can see what gem dependencies your app has by running rake gems.

However, this still doesn’t package these gem dependencies with the app, it only refers to system-dependent gems. If you want to pull these gems into your application source you can do so with the new rake gems:unpack task:

1
2

# Unpack all gems to vendor/gems
rake gems:unpack

You can also unpack individual gems:

1
2

# Unpack only the hpricot gem to vendor/gems
rake gems:unpack GEM=hpricot

This will unpack the gem into the vendor/gems/hpricot-0.5 directory which is automatically searched as part of the config.gem startup.

Your deployment strategy can now choose to automatically install required gems in each target environment or just package gems as part of the application source.

Update: Just added is the ability to build gems that have native extensions:

rake gems:build

tags: ruby, rubyonrails

In lock-step with the recent dirty objects functionality comes the ability of ActiveRecord models to perform partial updates – which only saves the attributes that have been modified on updates.

For instance:

1
2
3
4
5
6
7
8
9
10

article = Article.find(:first)
article.title  #=> "Title"
article.subject  #=> "Edge Rails"

# Update one of the attributes
article.title = "New Title"

# And only that updated attribute is persisted to the db
article.save
  #=>  "UPDATE articles SET title = 'New Title' WHERE id = 1"

Note: Your updated_at/on magic fields will only be set if there are unsaved attributes that need persisting. If there are no changed attributes for the object being persisted then there won’t be any SQL updates made.

To disable this functionality, set partial_updates = false for each model you wish to not take advantage of partial updates. To disable this system-wide add this line to your environment.rb or, better yet, in a config/initializer:

ActiveRecord::Base.partial_updates = false

Note: There’s currently a config/initializers/new_rails_defaults.rb file that has this setting, so edit that file if you have it.

tags: ruby, rubyonrails