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
