There are incredible benefits to separate migrations from the model.
Also note that it is not so obvious that the procedural code to write
and track changes to the database code is 'duplicate' of what defines
the abstract structure of application domain.
Advantages, some philosophical, some more practical:
1) Abstraction
Think in terms of classes, modules, attributes and relationships
when designing the model, think in term of columns and tables when
migrating database
2) Switch from/to different ORMs (direct consequence of point 1)
3) Faster development (write only 'has_and_belongs_to_many' instead
'create_table ...'
4) Probably the most significant: reuse of code.
about the reuse of code I just can not understand how this failure has
not been felt in all these years, and this is the only reason that
makes me doubt that there are deep reasons for not adopting such a
solution.
A use case: Imagine you write an application with a user model. In
time, our user model is refined until it becomes almost perfect so is
it right that we would like to reuse the same scheme for other
applications because it is so good. Suppose you have to do this for a
class Player.
It would be so uncomfortable that we resort to definitely do a
copy-paste from schema.rb in a brand new migration, changing 'user'
with 'player'
And if we would distribute our schema? We need to create a generator
for that. Now check the difference:
module Profile
extends ActiveSupport::Concern
included do
field :name
field :age, :integer
# ..and so on
end
end
class Player < ActiveRecord::Base
include Profile
end
rails g migration create_players --from Player
done!
There are thousand of advantages on doing so, but I do not wanna waste
your time anymore ;).
But please check my implementation here:
https://github.com/mcasimir/active_record_schema
and think how useful it can be if gems such as paperclip or
friendly_id were be supported by this behaviour here:
gem 'friendly_id_schema', :git => 'git://gist.github.com/2629071.git'
gem 'paperclip_schema', :git => 'git://gist.github.com/2629431.git'
Plus note that you can distribute schemas in a while using microgems.
---
mcasimir
2012/5/8 Tim Shaffer <timshaf...@me.com>:
> Seems like unnecessary duplication if you have to specify the field in a
> migration as well as in the model itself.
>
> What's the point of having to specify the field on the model if it's already
> in the table? Unless there is some other benefit that I am not seeing right
> away.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyonrails-core/-/H3ZxWdejlX8J.
> To post to this group, send email to rubyonrails-core@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.
--
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-core@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.
