4 ms·

This is a cool feature. Unfortunately, when I looked into this for our codebase, I found that it doesn't have full support in Rails 3. You can make the index,

This is a cool feature. Unfortunately, when I looked into this for our codebase, I found that it doesn't have full support in Rails 3. You can make the index, via a migration, but rails won't include it properly in your `schema.rb` file. So restoring via schema (as opposed to running through all your migrations from scratch) or just trying to understand your database by looking at schema.rb won't give you a full picture. However, looking at `add_index` in rails 4, it seems to support it! edit: one thing I did try out was you can change your schema file from `schema.rb` to `schema.sql`, which supposedly fixes it, but I had some issues with that which I don't remember at the moment.

drob 12y ago
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.
mcorrand 12y ago
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.
sanderjd 12y ago
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-working-on-heroku http://stackoverflow.com/questions/17300341/migrate-not-work...
- ikawe 12y ago
  > 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.
- andrewvc 12y ago
  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.
pjungwir 12y ago
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 https://github.com/pjungwir/db_leftovers

drob 12y ago

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.

mcorrand 12y ago

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.

sanderjd 12y ago

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-working-on-heroku http://stackoverflow.com/questions/17300341/migrate-not-work...

ikawe 12y ago
> 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.
andrewvc 12y ago
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.

pjungwir 12y ago

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 https://github.com/pjungwir/db_leftovers