Hi everybody,
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.
Many thanks in advance.
Best regards,
Marco Antonio
Marco Antonio F. wrote in post #991464:
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?
On Thu, Apr 7, 2011 at 4:02 PM, Ar Chron [email protected] wrote:
Create the new table.
Migrate the data.
Once and done.
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.
On Apr 8, 2:21am, Marco Antonio F. [email protected] wrote:
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 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.
My 2c,
\Peter