I'm having fun with a legacy DB (SQL Server), and in the process found
some code in rails/lib/tasks/databases.rake which feels wrong.
0) Errors which occur during this phase of a rake:test or rake:spec
tend to be ignored, although they are logically fatal. In the best
case, this means that the stack trace when an error finally does
manage to stop the process is worthless. Best case.
1) Prepare's strategy is to dump the current schema, blow away the
test db, and then rebuild the test schema from the dump. This strikes
me as dangerous in the event that someone has mucked with the db
outside of a migration--that is, made a change that won't get
reflected in source control. Wouldn't it be safer to just blow away
the test db & do the migrations to rebuild?
2) db:structure:dump for sqlserver requires the scptxfr executable,
which is part of the SQLServer package--not the client. While it is
likely that developers can get access to this file (and its supporting
files), there is no a priori reason to believe that a developer is
going to have access to this expensive bit of software. More
generally, should we not restrict dependencies to client code? (The
scptxfr script went away with SQLServer 2005, so this particular code
is also aging.)
3) Several of the tasks in the db namespace have code of the form
when "mysql", "oci", "oracle"
This is generally considered bad practice ("hypnotic" coding). It is
not extensible, and it breaks the model of separating out code for the
commercial databases. Does rake support calls to computed tasks?