Oh Sorry! That works! I had a migration with new_email later. That was
causing problem! My bad
And that’s why you shouldn’t use migrations for db load. I know it’s a
very common practice, but I don’t support it since it’s error-prone.
Migrations are really useful for dynamic db schemas, I mean, schemas
that will change over time. If schemas never changed, then we wouldn’t
need any migrations but just a static copy of the creation sql. So, even
only for the sake of argument, we can say the use of migrations implies
changes to your tables/models.
And talking about models, there is this one nice thing with them which
is validations. So let’s say I create a table in step 1 and I add a
statement for creating a new row/instance of that Model. Then let’s say
in step 35 I add a new mandatory not null field and I accordingly set my
validations, since in Rails we usually put the load of validating on the
Now, when I try to install my project on a new server, step 1 of
migrations will crash, since validation is going to fail because of the
Assuming your problem is only validations and not call-backs, you could
always try saving your objects with save(false). Problem with this
approach is you are not going to run validations, so you better be sure
what you are doing.
My solution for this is using migrations only for dealing with the
DDL, so anything which is not a part of the schema definition is
definitely out of my migrations code. And where should I put my
initializations then? I like to create a task to initialize all my db
It comes handy also because I can put all my initializations in one
single file and I don’t need to be checking the migrations code. And
since when you update the code of the new migrations from the
repository you are also updating the code for the tasks, you can always
put the most recent version in your task code without any problems.
If you commit your changes of both migration and task together, then you
can go back to any release you want and your rake task will always be in
sync with your migrations. Also, if when you commit a model with
references to new fields you comment in your scm which migration it
belongs to, then you have everything wrapped up and you can go up/down
versions of your project without any issues.
Now you can do something like
And to make it really comfortable and avoid problems, don’t insert the
new objects starting with “Model.new” or “Model.create” but with a
“Model.find_or_initialize_by…”. That way if you already inserted the
row in db, you are not going to get duplicates.
I’m sure there are other approaches to this problem, but this one seems
to work fine for me.