66b4fafc35
Previously, if you ran: ``` rake dev_up test_up ``` It would migrate the development database up, and then not migrate the test database up. That's because dev_up would set `RACK_ENV=development`, then run `require_relative "db"`. This would load your development database into `DB`. When test_up runs, it would set `RACK_ENV=test`, then run `require_relative "db"`. However, as the `db.rb` has already been required, this is a no-op. So `DB` still points to the development database. Since it has already been migrated, nothing happens. This change has test_up raise an error instead of silently not migrating. If we want `rake dev_up test_up` to work correctly instead of failing, we need to move the logic to a script that rake can execute as a separate program. This is how most of the rake tasks are run already. Only the migration and annotate tasks access the database directly. This fixes annotate to use the test environment instead of the development environment. In general, annotate is run automatically by test_up, and rarely run manually, so it ended up using the test environment anyway in that case. If you run into problems (e.g. annotation changes due to migrating down and back up), it's much easier to wipe your test database than your development database. This also removes the sequel require from the top of the Rakefile, which fixes cases where a bare `rake` would not run at all from a direct repository checkout after `bundle install` if the Gemfile loaded `sequel` from `github`, unless `sequel` was already installed as a gem. In addition to fixing that case, it makes almost all rake tasks faster by not having to load sequel.
12 KiB
12 KiB