migration tries to drop tables that don't exist in a clean DB

[YenTheFirst]

https://github.com/codeforamerica/schoolselection/blob/master/db/migrate/20111009042810_remove_legacy_database_tables.rb

[joelmahoney]

Some of these have definitely been removed (e.g. mail_clusters). You should
look at the recent, relevantly named migrations. Not sure why or where
these tables are showing up for you.
On Nov 1, 2011 4:03 PM, "T S" <
reply@reply.github.com>
wrote:

https://github.com/codeforamerica/schoolselection/blob/master/db/migrate/20111009042810_remove_legacy_database_tables.rb

Reply to this email directly or view it on GitHub:
#1

[YenTheFirst]

they're NOT showing up, that's the problem.

starting from a fresh database, and migrating, these tables are never created, but this migration tries to drop them, causing it to fail.

[joelmahoney]

I think it's because 'rails destroy scaffold' nukes migrations, too. I guess we should remove the drop statements from the later migrations.

On Nov 2, 2011, at 8:55 AM, T S wrote:

they're NOT showing up, that's the problem.

starting from a fresh database, and migrating, these tables are never created, but this migration tries to drop them, causing it to fail.

Reply to this email directly or view it on GitHub:
#1 (comment)

[lovehandle]

I believe it's considered standard practice to load the schema prior to running migrations, and this issue does not seem to occur when migrations are run after the schema has been loaded. Perhaps the drop statements should still be removed, but it seems like a non-issue imo.

The above commit updates the README to show loading the schema as part of the installation process.