Rails - Apr 2011 - Need help in changing data in production.

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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Marco Antonio Filho 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?

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Thu, Apr 7, 2011 at 4:02 PM, Ar Chron
<lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
> Marco Antonio Filho 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 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.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Apr 8, 2:21 am, Marco Antonio Filho
<marcoafi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.