On Jul 8, 2010, at 2:23 PM, Neeraj Singh wrote:
I see you point. And I agree. However I still think that rails should take some of the responsibility and should clarify to user following things. 1) create_table :users, :id => false, :primary_key => :user_id do |t| t.integer :user_id t.string :name t.timestamps end Rails should throw an error rather than setting no column as primary key. 2) create_table :users, :primary_key => :user_id do |t| t.string :user_id t.string :name t.timestamps end Rails can clearly see that user is setting user_id column as string. Still rails goes ahead and creates a column which is integer . That's just wrong. In the above two cases rails can just throw an error rather than doing things in an opinionated way without any warning.
Throwing errors in migrations for all but the most extreme errors is VERY BAD - several popular databases don't have transactional DDL, so the result of erroring out of a migration partway through can be a DB that can't go forward (errors / existing tables) and can't go back (tables missing for the down migrations).
I suspect that's why create_table does it's best to muddle through despite somewhat contradictory options.
--Matt Jones -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
