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 case abcs[blah]["adapter"] when "mysql", "oci", "oracle" ... when "postgresql" ... when "sqlserver" ...
... end
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?