[keredson]

True, this doesn't do data migrations, and we still write the occasional(1) data migration when needed. But those are no more difficult to write, and the much more common non-data migrations are an order of magnitude easier. So net win.

(1) If your data migrations are not "occasional" (and I mean very occasional) that's a sign you're doing a poor job at modeling your data. Splitting one column into two is almost always an example of someone really f-ing up the original schema.

Think of it this way: how do you switch branches? Do you look up the most recent ancestor, check it out, migrate down to it, then back up the new branch? It's so hard I don't know any rails devs who actually do it. But with a my tool it's a one-line command. PRs w/ schema changes actually get tested now, not just eyeballed.

Also, did you even read the "rant"? Do you seriously like the proposed version control tool modeled after rail's migrations? ;)

[morokhovets]

I was under impression that you suggest not to use migrations at all. That "hybrid" approach you just described seems to make sense :) Still not sure if I'm going to try it in production.

As of occasional (or not) data migrations, it depends on project and its history. If project is live, rapidly developed and has faced couple of pivots, migration history will reflect it.

[keredson]

Just to clarify, to me "data migration" is just a fancy name for a one-off script that you run during (or after) a deployment. We don't actually use the rails migration for it. (Mostly because it would overwrite our schema.rb IIRC.) But in general, yep.

[morokhovets]

So how do you manage these scripts? When deployment is multistaged and automated you won't just run them by hand. You need system that runs them automatically and exactly one time at each stage. I can't see why you have to create a system to manage these scripts if there is good enough built-in system for that purpose?

If automated deployment is not your case I strongly recommend it. Since I first time managed autodeploy to work properly I've never looked back. It is SO convenient.

I may be wrong again about your processes and configuration :)

[keredson]

we do auto-deploy, but they aren't required to be run during the deploy process, so we just run them sometime after the deploy. but honestly i can count on one hand the number of these we do a year - i haven't put much effort into streamlining the process. whereas schema changes are quite regular. just had one tonight in fact. output from the deploy log a few mins ago:

  Executing in 3...2...1...

  BEGIN TRANSACTION

  -- column changes for table products
  ALTER TABLE "products" ADD COLUMN "dont_email_on_purchase" boolean

  -- column changes for table searches
  ALTER TABLE "searches" ADD COLUMN "tag_only" boolean DEFAULT 'f'

  COMMIT

  --==[ COMPLETED ]==--

from the one line code change that triggered it:

  1  db/schema.rb
   @@ -543,6 +543,7 @@
  
      create_table "searches", :force => true do |t|
        t.text     "query"
   +    t.boolean  "tag_only",         :default => false
        t.datetime "searched_at"
        t.integer  "user_id"
        t.integer  "page_id"

(well, there were two commits obviously)