Hi,
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 application-side.
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
non-existing field.
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
content.
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
rake db:migrate
rake my_project:initialize_db
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.
Regards,
javier ramirez
