• Rails default database is now sqlite3. If you are running Leopard, everything is already setup for you. As DHH mentioned, just “rails -d mysql yourappname” if you want to generate a new app preconfigured for MySQL.
  Sqlite3 is great and if the only reason why you didn’t give it a try is because you have to use CocoaMySQL, then check out sqlitebrowser

• Other new feature: rake secret to generate a key used to encrypt your session. Really useful task when you’re migrating an app to 2.x

• To improve performance, some changes were made to the template caching and you have to restart your production server after a template modification.

• Validates acceptance of still works for non-existent tables . (sorry Josh, I won’t post after 2am, especially when I forget your life changing bug fix )

• Added option to pass proc to ActionController::Base.asset_host for maximum configurability. Example:

1
2
3
4
5
6
7

    ActionController::Base.asset_host = Proc.new { |source|
      if source.starts_with?('/images')
        "http://images.example.com"
      else
        "http://assets.example.com"
      end
    }

• Finally, I added 2 new rake tasks: db:migrate:redo and db:migrate:reset
  
  db:migrate:redo rolls back your database and then migrates it up. You can define the STEP constant to specify the amount of steps you want to rollback. This task is very useful in development mode when making a modification to the latest migration(s).
  db:migrate:reset will drop your database, re create it and migrate it up. Only use this task if you really have to and only in development/test environment. Use db:reset in production mode since it uses the schema.rb file and won’t go through the hundreds of migrations you might have.

Changeset

2.0.2 (December 16th, 2007)

• Changed the default database from mysql to sqlite3, so now running “rails myapp” will have a config/database.yml that’s setup for SQLite3 (which in OS X Leopard is installed by default, so is the gem, so everything Just Works with no database configuration at all). To get a Rails application preconfigured for MySQL, just run “rails -d mysql myapp” [DHH]

• Turned on ActionView::Base.cachetemplateloading by default in config/environments/production.rb to prevent file system stat calls for every template loading to see if it changed (this means that you have to restart the application to see template changes in production mode) [DHH]

• Introduce rake secret to output a crytographically secure secret key for use with cookie sessions #10363 [revans]

• Fixed that local database creation should consider 127.0.0.1 local #9026 [parcelbrat]

• Fixed that functional tests generated for scaffolds should use fixture calls instead of hard-coded IDs #10435 [boone]

• Added db:migrate:redo and db:migrate:reset for rerunning existing migrations #10431, #10432 [matt]

• RAILSGEMVERSION may be double-quoted also. #10443 [James Cox]

• Update rails:freeze:gems to work with RubyGems 0.9.5. [Jeremy Kemper]

• Added deleteviaredirect and putviaredirect to integration testing #10497 [philodespotos]

• Allow headers['Accept'] to be set by hand when calling xmlhttprequest #10461 [BMorearty]

• Added OPTIONS to list of default accepted HTTP methods #10449 [holoway]

• Added option to pass proc to ActionController::Base.asset_host for maximum configurability #10521 [chuyeow]. Example:

  ActionController::Base.asset_host = Proc.new { |source|
  if source.starts_with?(‘/images’)
  “http://images.example.com”
  else
  “http://assets.example.com”
  end
  }

• Fixed that ActionView#fileexists? would be incorrect if @firstrender is set #10569 [dbussink]

• Added that Array#toparam calls toparam on all it’s elements #10473 [brandon]

• Ensure asset cache directories are automatically created. #10337 [Josh Peek, Cheah Chu Yeow]

• render ml and :json preserve custom content types. #10388 [jmettraux, Cheah Chu Yeow]

• Refactor Action View template handlers. #10437, #10455 [Josh Peek]

• Fix DoubleRenderError message and leave out mention of returning false from filters. Closes #10380 [Frederick Cheung]

• Clean up some cruft around ActionController::Base#head. Closes #10417 [ssoroka]

• Ensure optimistic locking handles nil #lock_version values properly. Closes #10510 [rick]

• Make the Fixtures Test::Unit enhancements more supporting for double-loaded test cases. Closes #10379 [brynary]

• Fix that validatesacceptanceof still works for non-existent tables (useful for bootstrapping new databases). Closes #10474 [hasmanyjosh]

• Ensure that the :uniq option for has_many :through associations retains the order. #10463 [remvee]

• Base.exists? doesn’t rescue exceptions to avoid hiding SQL errors. #10458 [Michael Klishin]

• Documentation: Active Record exceptions, destroyall and deleteall. #10444, #10447 [Michael Klishin]

check out the plugin page

File structure will look like that:

I use this plugin to backup my apps running in production. When I need to debug an application, I just need to restore the db locally and debug. The fact that it uses fixtures helps me finding data quickly and I can easily decide to only restore few tables.

I also have a Capistrano recipe to create backups before each deployment.

oohh and the plugin is Sake compatible, give it a try

Enjoy

UPDATE: Ryan Daigle covered the new added features in his blog
How cool is that?

That’s a great achievement that I owe to josh Knowles and Josh Susser

Josh Knowles and Matt Heidemann from Integrum started working on rake_tasks a little while ago. I helped them hacking this cool plugin. After a while, we realized that the plugin was getting too big and we decided to split it in two:

• db_tasks
• svn_tasks

Without telling the other guys (sorry!), I started discussing merging some of the rake_tasks plugin in Rails core.

I then submitted my patch following Josh Susser recommendations.

Today, Josh congratulated me on the merge. I’m quite glad/proud that our work made it to Edge.

What’s that patch anyway?

Here are the 2 features my patch added to the future Rails 2.0:

• MySQL: create_database takes :charset and :collation options. Charset defaults to utf8.
• Add db:create, drop, reset, charset, and collation tasks

That means that you cna now do that:

$rails my_app
$rake db:create
$ruby script/server

That’s it, you have a working Rails app!! Well, almost, there’s nothing it in yet but at least your databases are created. Ohh, and your database is unicode, that also means that all your new tables will be utf8.

Enjoy

The thing is that the plugin was getting too big when I started hacking the MySQL adapter and adding utf-8 support we figured out it was smarter to split the plugin and create dbtasks and svntasks

I temporarily hosted db_tasks there:

http://svn.aimonetti.net/public/plugins/db_tasks/

ruby script/plugin install http://svn.aimonetti.net/public/plugins/db_tasks/

check your Rake tasks:

• rake db:create Creates the databases defined in your config/database.yml (unless they already exist) You can also specify the charset and collation you want your dbs to use: rake db:create CHARSET=’latin1′ COLLATION=’latin1_bin’)
• rake db:drop Drops the database for your currenet RAILS_ENV as defined in config/database.yml
• rake db:reset Drops, creates and then migrates the database for your current RAILS_ENV
• rake db:shell Launches the database shell using the values defined in config/database.yml
• rake db:charset Returns the charset of your current RAILS_ENV database
• rake db:collation Returns the collation of your current RAILS_ENV database
• rake db:update_connection_settings add the encoding format to each environment in the database.yml file

By default, your new databases will be utf8, you can automatically create your databases by typing:

rake db:create

or reset your databases (drop, create, migrate)

rake db:reset

Another simple plugin for lazy developers.

It was actually simpler than I expected. I simply followed this post and almost everything went ok.

sudo port install postgresql81 +server

will install postgresql

sudo gem install postgres -- --with-pgsql-include-dir=/opt/local/include/postgresql81 --with-pgsql-lib-dir=/opt/local/lib/postgresql81

Will do a gem install

Start your server automatically by doing:

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql81-server.plist
sudo launchctl start org.macports.postgresql81-server

Create a folder for your dbs
mkdir /opt/local/var/db/pgsql/data

Add pgsql to your path (I use textmate)

mate ~/.profile

My path looks like that:

export PATH=/opt/local/bin:/opt/local/sbin:/opt/local/apache2/bin:/opt/local/lib/postgresql81/bin/:$PATH

export PGDATA="/opt/local/var/db/pgsql/data"

restart your shell (or open a new tab) and type
initdb -D /opt/local/var/db/pgsql/data

Success. You can now start the database server using:

postmaster -D /opt/local/var/db/pgsql/data

or
pg_ctl -D /opt/local/var/db/pgsql/data -l logfile start

Now, create your db: $ createdb test -E utf8 or drop your newly created db: $ dropdb test

That’s it, it was easy.

more info from apple

In this post I’ll try to go through setting up a plugin for migration and start using RSpec for developing the migration plugin.

What we want is to migrate sites using the legacy application to our new Rails application. That means that new users won’t be be migrated. It therefore makes sense not to add the migrating logic to the main application but to create a plugin. (if you are not familiar with Rails plugins check this blog post from Geoffrey Grosenbach about plugins)

Let’s create our plugin

./script/generate plugin legacy_migration

Rails should have generated something like that:

legacy_migration
|-- init.rb
|-- install.rb
|-- uninstall.rb
|-- Rakefile
|-- README
|-- lib/
|   |-- legacy_migration.rb
|-- tasks/
|   |-- legacy_migration_tasks.rake
|-- test
|   |-- legacy_migration_test.rb

Since we are going to use RSpec, we can remove the test folder and create a spec folder. In our spec folder, let’s add some subfolders to organize our files. Let’s create a fixtures folder to hold, a helpers folder, a migrate folder (we’ll use that to migrate our legacy database) and finally, a models folder.

Our plugin folder should look more or less like that:

legacy_migration
|-- init.rb
|-- install.rb
|-- uninstall.rb
|-- Rakefile
|-- README
|-- lib/
|   |-- legacy_migration.rb
|-- tasks/
|   |-- legacy_migration_tasks.rake
|-- spec
|   |-- fixtures
|   |-- helpers
|   |-- migrate
|   |-- models

Great, let’s get started and let’s create our first spec. We should probably start by migrating users so I’ll create a new spec in the spec/models folder called legacy_user_spec.rb and add the following code:

require File.dirname(FILE) + '/../helpers/legacy_user_helper'
require File.dirname(FILE) + '/../helpers/spec_helper'

describe "a connection to the legacy application" do
  setup do
    @connection_status = LEGACY.connect
  end
end

it "should be connected to the legacy database" do
  @connection_status.current_database.should == ActiveRecord::Base.configurations'legacy'

end

Note that I’m using RSpec trunk/edge and I use “describe” instead of “context” and “it” instead of “specify”. For more information on how to run RSpec edge with TextMate read this previous post.

If we look at the code above, we start by requiring 2 helpers, a general helper called spec_helper and a helper just for this spec called legacy_user_helper (we will obviously need to create them otherwise our spec will failed).

Then we start our first spec by describing a connection to the legacy application and we specify that it should be connected to the legacy database.

Here is our setup code:

setup do
  @connection_status = LEGACY.connect
end

What I want is to retrieve a connection status after I connect to our legacy application. To manage the connection to the legacy application we will create a LEGACY module. We will need to connect to many legacy applications/sites and our module should help us doing that.

Then we can read that our spec checks that we are connected to the legacy database.

it "should be connected to the legacy database" do
  @connection_status.current_database.should == ActiveRecord::Base.configurations'legacy'
end

That means we want to compare the connection status to the ‘legacy’ environment defined in the database.yml file.

We now need to get this spec to pass.

Let’s get started by adding a legacy environment to our database.yml and creating our LEGACY module in our legacy_migration.rb file.

Add the following to your database.yml

legacy:
  adapter: mysql
  database: legacy
  username: root
  password:
  host: localhost

Now, let’s create the LEGACY module in our legacy_migration.rb file

module LEGACY

  # Connect to a Legacy database.
  # Usage:
  # Manual connection: LEGACY.connect(:database => 'legacy-database', :adapter => 'mysql', :username => 'root', :password => '', :host => 'localhost')
  # Auto connection to the database.yml defined legacy DB: LEGACY.connect
  # Connection to any database available in database.yml LEGACY.connect('legacy_test')
  # Connect a class to a specific database: LEGACY.connect(LegacyInstaller, ActiveRecord::Base.configurations['legacy_installer'])
  def self.connect(spec = nil, opt_env = nil)
    case spec
      # Automatically connect to the legacy environment database defined in the database.yml
    when nil
      raise 'Legacy Database not defined' unless defined? ActiveRecord::Base.configurations['legacy']
      LegacyActiveRecord.establish_connection(ActiveRecord::Base.configurations['legacy'])
      # Return the connections status
      LegacyActiveRecord.connection
      # A connection's name from the database.yml can be passed
    when Symbol, String
      if configuration = ActiveRecord::Base.configurations[spec.to_s]
        LegacyActiveRecord.establish_connection(configuration)
      else
        raise "#{spec} database is not configured"
      end
      # Connect a Model to a specific Database
    when Class
      raise 'Environment connection not provided or nil' unless defined? opt_env || opt_env['database'] == nil
      if spec.connection.current_database == opt_env['database']
        spec.connection
      else
        spec.establish_connection(opt_env)
      end
      # An array can be passed to establish the connection
    else
      spec = spec.symbolize_keys
      unless spec.key?(:adapter) then raise "database configuration does not specify adapter" end
        adapter_method = "#{spec[:adapter]}_connection"
        LegacyActiveRecord.establish_connection(spec)
      end
    end
  end

There we go, we have a really cool connect function, we can easily connect to the default legacy environment defined in the database.yml file, we can specify the connection settings, connect to another environment database and even connect one specific class/model to a specific environment. (that will useful since we have many databases). If we wanted to follow the TDD rules, I shouldn’t have written so much code… as a matter of fact, when I worked on this project I did not, but since I don’t have much time, I won’t go through the re-factoring steps.

One thing you might have noticed is that we establish a connection between LegacyActiveRecord and the legacy database. (instead of connecting ActiveRecord to the legacy database).

LegacyActiveRecord.establish_connection(ActiveRecord::Base.configurations['legacy'])

The problem is that we didn’t create the LegacyActiveRecord model yet. Let’s do that right away. Let’s add a new folder called models in our lib folder. In the models folder, let’s create a legacy_active_record.rb file and add the following code:

class LegacyActiveRecord < ActiveRecord::Base
  self.abstract_class = true
end

Cool, now let’s have fun with our new module, fire the console (./script/console) and try LEGACY.connect
Here is what we get back:

    >> LEGACY.connect
    => #nil, :database=>”legacy”, :allow_concurrency=>false, :host=>”localhost”, :username=>”root”, :adapter=>”mysql”}, @connection_options=[“localhost”, “root”, ””, “legacy”, nil, nil], [...]

let’s try to get the database we connected to:

>>LEGACY.connect.current_database
    => “legacy”

Awesome, we can now get our LegacyActiveRecord model to connect to our legacy database and return the connections status. Let’s run our specs……….. they pass.

Sweet, we setup our migration plugin, got our first spec written, added the code needed to get the spec to pass, I think we are done with PART 2