It is because Rails upgrading migration table schema_info to schema_migrations. While upgrade, Rails by default looks for old migration files under APP_ROOT/db/migrate, so it can insert 1..21 into schema_migration table. But in Radiant we have those files under APP_ROOT/vendor/radiant/db/migrate. So rails does not insert anything into schema_migration but schema_info removed. Then it tries to run all migration files from the beginning. Radiant schema files have force create on each table migration, so data is all lost.
Easy way to solve this is by soft linking the folder APP_ROOT/vendor/ radiant/db/migrate to APP_ROOT/db/migrate until migration is done. On Sep 27, 9:06 pm, "D.Kreft" <[email protected]> wrote: > On Fri, Sep 24, 2010 at 5:40 PM, D.Kreft <[email protected]> wrote: > > It certainly shouldn't do that. Are you sure you didn't run bootstrap? > > A bit more info... > > Here's what the old (0.6.7) migration_info table looks like: > > % sqlite3 development.sqlite3.db 'select * from schema_migrations' > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > 11 > 12 > 13 > 14 > 15 > 16 > 17 > 18 > 19 > 20 > 21 > 20081203140407 > 20090226140109 > 20090929164633 > 20091003095744 > Styles 'n Scripts-1 > Styles 'n Scripts-2 > Styles 'n Scripts-3 > Styles 'n Scripts-4 > Styles 'n Scripts-5 > Styles 'n Scripts-20091021092157 > Styles 'n Scripts Minifier-1 > Settings-1 > Settings-2 > > I'm presuming that the non-numeric versions injected by SNS and Settings are > what is causing the problem. My hunch is that the following query gets run > with the following result: > > % sqlite3 development.sqlite3.db 'select max(version) from > schema_migrations' > Styles 'n Scripts-5 > > This then causes every single migration to be run in db/migrate, starting > with 001_create_radiant_tables.rb, which of course forces pre-existing > tables to be wiped because of the :force => true option on every > create_table call in the file. > > Make sense? > > -dan
