3 ms·

1) The database holds the authoritative schema. You shouldn't duplicate it in your code. That's nonsense, your application implies the authoritative schema as

by moe 16y ago

1) The database holds the authoritative schema. You shouldn't duplicate it in your code. That's nonsense, your application implies the authoritative schema as it relies on a given set of model fields to exist. More importantly any given version of your application may imply a different schema. Artificially detaching the schema from the code only causes problems and adds pointless complexity to the overwhelming majority of applications (which don't share the database with anything else). Having to reach for irb or psql only to figure out what fields exist on a given model is backwards. Having to manually craft migrations with proper indexes, keys and constraints to match the separately defined validations and associations is completely ass-backwards.

snprbob86 16y ago
When a migration runs, the schema.rb file is regenerated. This way, each checkin contains a complete snapshot of the schema that goes with that code. (side note: I think that schema.sql should be the default, not schema.rb)
- moe 16y ago
  Yes, that's what everybody refers to when they quickly need to look up a field. However, having to look in two places to understand your model is a bit cumbersome, isn't it? Especially when complex associations come into play and you have to resolve the rails identifier magic in your head... And then there's the question of why you should have to refer to a cached copy of your schema when you could just spell it all out in one place.
  - jarin 16y ago
    If remembering attribute names is your concern, you can use an IDE or vim plugin for autocomplete, or just use annotated_models to add/update the schema down at the bottom of your model files on every db:migrate: https://github.com/openteam/annotated_models https://github.com/openteam/annotated_models
    - moe 16y ago
      You're proposing kludges for a problem that doesn't exist in declarative ORMs and that is far from the most serious issue of AR. My general point is that AR makes no sense for web applications.

by moe 16y ago

snprbob86 16y ago

When a migration runs, the schema.rb file is regenerated. This way, each checkin contains a complete snapshot of the schema that goes with that code. (side note: I think that schema.sql should be the default, not schema.rb)

moe 16y ago
Yes, that's what everybody refers to when they quickly need to look up a field. However, having to look in two places to understand your model is a bit cumbersome, isn't it? Especially when complex associations come into play and you have to resolve the rails identifier magic in your head... And then there's the question of why you should have to refer to a cached copy of your schema when you could just spell it all out in one place.
- jarin 16y ago
  If remembering attribute names is your concern, you can use an IDE or vim plugin for autocomplete, or just use annotated_models to add/update the schema down at the bottom of your model files on every db:migrate: https://github.com/openteam/annotated_models https://github.com/openteam/annotated_models
  - moe 16y ago
    You're proposing kludges for a problem that doesn't exist in declarative ORMs and that is far from the most serious issue of AR. My general point is that AR makes no sense for web applications.