I have to change a lot of data in production server and I don’t know what’s the best way to do it.
To handle the permissions in the older version of my system I had two models: Group and Permision.
class Group < ActiveRecord::Base
has_many :actions
end
class Permission < ActiveRecord::Base
belongs_to :group
PERMISSION_NAMES = “…”
end
I stored the application permissions inside the model. Now I did a lot of changes in this code and it looks something like this:
class Group < ActiveRecord::Base
has_many :actions
end
class Action < ActiveRecord::Base
belongs_to :group
belongs_to :permission
end
class Permission < ActiveRecord::Base
has_many :actions
end
The Permission model holds a list of permissions and their Id. It is like a domain table. This way a group can have many permissions and a permission can have many groups. Now comes the problem. I need to deploy these changes in the production servers. I already have the script to update the changes, but I don’t know what is the conventional place to put it. Not in the migrations, I know. I put them in the seeds file, but I think is even worse. Another important thing is that I would love to do some automated tests on my script. How can I do that.
Now comes the problem. I need to deploy these
changes
in the production servers. I already have the script to update the
changes,
but I don't know what is the conventional place to put it. Not in the
migrations, I know.
Why not a migration? Seems like the correct place for a one-shot
change.
Create the new table.
Migrate the data.
Once and done.
I've done this numerous times on a project as the design evolves (create
new table(s), reorganize existing data), and the migrations provide the
audit trail of the actions.
Just make sure your down action undoes everything appropriately, but
that's what your dev environment is for, isn't it?
I do agree with you. But I read so many articles that state that the migrations are supposed only to contain the structure of the tables, not changes in the records.
I think I will stick with the migration then. It seems the best place to put these scripts for now.
I get confused sometimes too, but what helps me is to think about it
this way: if you are moving data to conform to a new schema, then it
is really part of the schema change and ergo belongs in a migration.
However, if you are changing data for some other purpose (for example
requiring everyone to reset their password on next login after some
security issue), then that would belong in something more of a rake/
capistrano task since its not schema related.
I believe when people saying migrations shouldn't change the records,
they mean outside of changes required by schema changes, which are
what the migrations are supposed to address.