Thanks, worked like a charm! > My guess is that you CTRL-C'd out before the schema_migrations table got > copied. The contents of this table are how Rails knows which migrations have > been applied.
Yeah, that is what happened, though I'm not exactly clear on how the push clears out the schema_migrations table (as push doesn't clear out other tables), is that something hard coded into Taps? Seems pretty dangerous though, and if possible it should be fixed or at the very least warned about in the documentation. The schema_migrations table doesn't get sent until about 3/4 through my db:push, and if a db:push gets interrupted for any reason, like a connection failure, this would seem to leave the database in a state where a db:reset is necessary in order to get the application working again. > If my guess is correct and the corruption is just caused by the missing > schema_migrations data, then it will happen if you CTRL-C before that. I > wouldn't really call it corrupt, just incomplete. You could either reset and > repush, or probably just start another push on top of this one. Calling another push doesn't work. It errors out because of the fact that some of the data is already pushed up there, and this duplicates their primary keys. In tables without primary keys or other uniqueness enforcement, the behavior would be much worse I would guess, in that it would silently double up rows. I really hope this can be fixed, as otherwise using db:push or db:pull on any large database would seem to be a very high risk move for a live application. Any type of backup other than a bundle would need to be reuploaded, and the application would be inaccessible until then, which could be days for a big app. Mike -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
