Generating Migration Files With DATA Changes

Caleb wrote:

I would like to leverage the Rails migration functionality but use it
for producing migrate files that migrate DATA changes instead of SCHEMA
changes. For an example, instead of having:

class MigrateName < ActiveRecord::Migration
  def self.up
    add_column :users, :new_user_column, :float

  def self.down
    remove_column :users, :new_user_column

I need something like:

class MigrateName < ActiveRecord::Migration
  def self.up
    User.create({:id => 5, :name => "John"})
    User.create({:id => 6, :name => "John2"})
    User.update(2, {:name => "Mary_after"})

  def self.down
    User.create({:id => 1, :name => "Jack"})
    User.update(2, {:name => "Mary_before"})

This way running 'rake migrate' will update to the latest DATA SET.
Anyone try to do something like this before? Is this a good way to go
about doing this? I know I could just do DB dumps to flat files, but
these databses could get quite large and I would like to have
'relatively' small migrate files that are much more usable than flat DB

Another way I thought of doing this was to produce patch files from
running diff and keep track of these. However, something like the above
seemed more elegant.

The tricky part here is that in order to produce these migrate files, I
need to be able to have two different databases to compare against. How
can I use one ActiveRecord class but programmatically switch what DB it
is pointing at? I imagine that some sort of factory would be needed for
this. For example:

user_from_db1 = ObjectFactory(User.find_by_id(22), "DB1")
user_from_db2 = ObjectFactory(User.find_by_id(22), "DB2") # "Fred" # "Alice"

At this point I could then determine what to write in both the self.up
and self.down methods above if I were iterating through each user to see
how DB1 and DB2 were different.

This looks like it will be somewhat complex, so I'm mainly looking to
see if anyone has successfully tackled this before or if anyone knows of
a better way to do this.

Posted via

Migrations can pretty much run arbitrary code in the up and down
methods. The only time it's an issue is if you change the model and
then try to manipulate objects in the same migraiton.

It should not be too difficult to have a migration load a fixture into
a database table from a YAML file.