Rails - Nov 2005 - Rails Migration killed my data?

Ouch.

I just wrote a migration file to add created_on and modified_on
columns to a bunch of tables.  I ran it once and there was a typo in
one of the table names.  I fixed that in the file, but when I went to
check and see if the migration changes were "all or none," I noticed
that all of my data was missing.

So, any ideas on what happened?

Sean

> So, any ideas on what happened?
Migrations log all the SQL it runs to the regular log file. You should
be able to decipher what went down.

In general, though, it''s a bad idea to run untested migrations on live
data.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

Besides testing that migrations works on a backed up version of the database
before runnig on production database, isn''t it recommended to perform
each
migration step in a transaction (to attain "all or none")? If so, is
that
documented somewhere?

--
Jonas Bengtsson (jonas.b-7XRkppT4KCs@public.gmane.org)
http://andthennothing.net


--- rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org wrote:
Ouch.
> 
> I just wrote a migration
file to add created_on and modified_on
> columns to a bunch of tables.  I
ran it once and there was a typo in
> one of the table names.  I fixed that
in the file, but when I went to
> check and see if the migration changes
were "all or none," I noticed
> that all of my data was missing.
> 
> So,
any ideas on what happened?
> 
> Sean
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Well, it wasn''t production data, so reloading wasn''t an issue.

Based on the log, here''s what I think happened.

I had 2 migration files, and my database was at version 2.  I added a
third.  In the process of adding the third, I noticed something wrong
with the first (initial) migration script, so I edited it.

I saved versions 1 and 3 and ran ''rake migrate''.  Is it
possible that
Rails saw the changed timestamp on the first migration file and
decided to run from scratch?

If that''s the case, since I didn''t have any data INSERTS in my
first
migration file, everything was nuked with the DROP TABLE commands.

Does my theory hold any water?

Also, what is the best way to test migrations?

Thanks,

Sean

On 11/1/05, David Heinemeier Hansson
<david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Migrations log all the SQL it runs to the regular log file. You should
> be able to decipher what went down.
>
> In general, though, it''s a bad idea to run untested migrations on
live data.

> I saved versions 1 and 3 and ran ''rake migrate''.  Is it
possible that
> Rails saw the changed timestamp on the first migration file and
> decided to run from scratch?
It goes by the numbers in the filename, not file timestamps AFAIK.


--
rick
http://techno-weenie.net

Hi !

2005/11/1, Sean Hussey <seanhussey@gmail.com>:
> I saved versions 1 and 3 and ran 'rake migrate'.  Is it possible
that
> Rails saw the changed timestamp on the first migration file and
> decided to run from scratch?
>
> If that's the case, since I didn't have any data INSERTS in my
first
> migration file, everything was nuked with the DROP TABLE commands.
>
> Does my theory hold any water?
I don't think so.  Rails looked at the current version, saw 2,
incremented by 1 (3), tried to find a migration named 3_*, ran that,
then looped back - 3+1 = 4, search for 4_*, found none, break.

Is it possible that your config/database.yml file has the same
databases for dev, production and test environments ?
> Also, what is the best way to test migrations?
dump or copy your database, run the migrations on that copy, and then
do it for real.

For example, using MySQL:

mysqldump rails_production | mysql rails_development
rake migrate RAILS_ENV=development default

(The default task runs all unit and functional tests)

Then, if all goes well...
rake migrate RAILS_ENV=production

Hope that helps !
François

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 11/1/05, Francois Beausoleil
<francois.beausoleil-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Is it possible that your config/database.yml file has the same
> databases for dev, production and test environments ?
Nope.  Heck, I don''t even have a production database or environment
yet.
> dump or copy your database, run the migrations on that copy, and then
> do it for real.
Ok, so there''s no Railsian ''rake do_what_I_want'' for
this (yet).
Cool.  Just checking.

Thanks!

Sean