There's a simple solution to this:

    config.active_record.schema_format = :sql

In my opinion, this should be the default. I'm really not sure what advantage the schema DSL in schema.rb has over the ability to express the full schema in its native tongue.

Edit: Just saw your edit. This[0] may have been the problem you had with using :sql as the schema format. The counter-intuitive workaround is to output ruby in production. It seems weird, but doesn't hurt anything.

[0]: http://stackoverflow.com/questions/17300341/migrate-not-work...

> I'm really not sure what advantage the schema DSL in schema.rb has over the ability to express the full schema in its native tongue.

I always end up using the sql format, because sooner or later I do something remotely non-trivial in postgres. But I'll try to answer your implicit question...

schema.rb works just fine for sufficiently simple schema, it's easier to make sense of in version control, and it's backend agnostic, so if someone wants to develop the app on sqlite - that's just fine.

Of course, all these things become a downside when your setup is sufficiently complex - but if you are not using any interesting database features it's fine. In particular, I would almost never recommend developing against a different DB than you are deploying on. Sooner or later you'll be bit by a behavioral difference.

To add to this, the schema.rb or structure.sql files rails makes are never 'accurate'. By which I mean, they simply record the state of the database at the time of the last migration. If you are switching between branches, for instance, it will have columns from both branches.

We gitignore schema.rb because it is really useless. It's a performance optimization that causes more trouble than its worth.

The problem of syncing the schema to the orm is a tough one to solve indeed. Good to see that rails will get it right.

Django with South has the same issue, so much so that South preventatively overrides the native manage.py syncdb command with its own migrate command which replays all the migrations.

Here is a gem I wrote that uses a separate DSL to track indexes (including partial indexes), check constraints, and foreign keys. Rails 4 is starting to make this gem obsolete, but it still offers more than you get from vanilla Rails.

https://github.com/pjungwir/db_leftovers

I wonder if this has something to do with differential support from different DBs. I don't think MySQL has an equivalent feature, though I think SQLite does.