1.5.5 (2010-03-15):

Thanks to ngmoco.com (http://github.com/ngmoco) now DbCharmer supports one more use-case
for multi-db migrations. Now you can run the same migration on many databases at once.
For example, the following migration would create test_table on all three shard databases:

    class MultiDbTest < ActiveRecord::Migration
      db_magic :connections => [ :shard01, :shard02, :shard03 ]

      def self.up
        create_table :test_table do |t|
          t.string :test_string
          t.timestamps
        end
      end

      def self.down
        drop_table :test_table
      end
    end

----------------------------------------------------------------------------------------
1.5.4 (2010-03-12):

Added DbCharmer.with_remapped_databases, so that you can change the connection for
many models simultaneously, and implicitly. Very useful for work where you want to use
a particular slave for a whole range of database access.

----------------------------------------------------------------------------------------
1.5.3 (2010-03-10):

Few changes:
 * Colorized connection names in the logs for development mode
 * We do not log connection names when connection does not exist

----------------------------------------------------------------------------------------
1.5.1 (2010-03-06):

In this version we've added support for connection names logging in Rails queries log.
New log records have [connection_name] prefix for all queries that are executed on
non-standard connections:

[logs]   LogRecord Columns (1.1ms)   SHOW FIELDS FROM `log_records`
[logs]   User Delete all (0.1ms)   DELETE FROM `users`
[slave01]   User Load (0.2ms)   SELECT * FROM `users` WHERE (`users`.`login` = 'foo')

----------------------------------------------------------------------------------------
1.4.6 -> 1.5.0 (2010-03-05):

Major change in this version of DbCharmer is association preload support. For example,
let's say we have a schema:

    class Post < ActiveRecord::Base
      belongs_to :user
    end

    class User < ActiveRecord::Base
      has_many :posts
    end

Now, if we have the following call in our code:

    User.on_db(:foo).all(:include => :posts)

In 1.4.6 it would load the users from connection :foo and posts from the
default connection, which is not what we would expect from this line of code.
So, starting 1.5.0 all finder calls on models having :include parameter would
switch associated models' connections to the same connection as the main model
in the call.