On Fri, Sep 24, 2010 at 5:40 PM, D.Kreft <d...@kreft.net> 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

Reply via email to