As Matt pointed out offline, we shouldn't be running the migrations for a new developer.
"Even in this case, you'll want to run something like db:setup (which creates the db, loads the schema from db/schema.rb and seeds it) rather than mucking around with re-running all the migrations." Unfortunately, db:setup produces the same results: $ rake db:setup ... rake aborted! Table as does not exist -Sean On Jan 22, 2:21 pm, VegHead <[email protected]> wrote: > Shoot. Accidentally replied directly to Matt Jones. *sigh* > > On Jan 22, 1:40 pm, Matt Jones <[email protected]> wrote: > > > On Jan 22, 2010, at 2:30 PM, VegHead wrote: > > > > Yup. Basically started with a brand new database... no tables at all. > > > Even in vanilla Rails, migrating on a blank DB isn't the preferred way > > to clear the db - rake db:reset should work better, and has the > > advantage of re-seeding the DB, if your using the db/seeds.rb stuff > > added in Rails 2.3. > > There is a scenario where it is normal for the user/developer to have > a blank db: adding a new member to the development team. > > In fact, that's how I discovered this. Another developer checked out > the project, added the necessary database users, created the databases > and tried to run the migrations. He immediately ran into the "Table > foo does not exist" error. > > That's also why I was testing with a blank database - I was trying to > recreate his experience. > > -Sean -- You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en.
