Hacker News Reader

Comment by keredson | Hacker News Reader

one thing i hate about rails is writing the database migrations. (i thought: "why not just define what the schema should be, and let a diff-like tool figure out update statements?") so that's what i wrote:

https://github.com/keredson/ruby-db-evolve

been using it in production for ~1y now.

View on HN

I may be wrong but it looks that you just misunderstood what migrations offer and their usage patterns. What if you have to remove one column and split its data into two new ones? I can provide dozens of similar examples from my production code. In short, migrations are not only about schema metadata.

It would make more sense if your gem would generate migrations from schema.rb changes.

Also, that rant at the end of README kinda shows that you're hating the tool you're trying to use. Why not use another? You are not tied to ActiveRecord.

I'm not trying to say that migrations are flawless as a tool. I've faced at least one major problem with them. But still.

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? ;)

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.

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.

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 :)

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)

Agreed.

I understand the skepticism. I presented it at the Houston Ruby group last year, shortly after developing it. You should have seen the looks at the start. But try it on your own project. (It takes like 30 seconds to switch.)

Nice! I program in both Rails and Django and I really like Django's way of both having the schema with the models (it's a form of documentation) and the clever way it can write migrations for you.

hah. then you'll love this: this project was conceptually a port of a django tool i wrote ages ago: https://github.com/keredson/deseb

rather than call "./manage.py syncdb", call "./manage.py evolvedb" and changes to your models will be synced to your schema non-destructively. (ie: without dropping and re-building the table)

Reply on news.ycombinator.com