The difference is that, in our current example, we are using migrations not only to manage our
schema but also to populate various tables within our schema. When you use migrations in this dual-purpose
way, it is better to give up some of the abstraction by using direct SQL rather than give up the ability to move
from one version to another because of the use of models within your scripts.
Another common scenario where you may be tempted to reference your models within
migrations is when you need to load static data into the database. It is much better to use
YAML files (i.e., fixtures within Rails) to perform load operations. Fortunately, Ruby on Rails
has a rake task specifically for data loading chores, available at db:bootstrap. Again, if you are
CHAPTER 3 ?– SETTING UP YOUR DATABASE 56
working outside of Ruby on Rails, we still recommend writing a script to load YAML files or
another data format to store and load your basic set of application data into your database,
rather than using migrations.
Migrations Are Easier Than They Sound
Migrations are one of the hardest concepts for new Active Record programmers to truly grasp,
because the concept goes somewhat against the SQL-heavy traditional development process
most of us have been successfully using for years.
Pages:
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168