It is not clear to me why dumping a database using the databases.rake structure:dump task should ALWAYS have to write to schema_migrations (by calling ActiveRecord::Base.connection.dump_schema_information) if the database supports migrations as Postgres does.
Currently the task returns a fatal error if the schema_migrations table does not exist.
Firstly, and I am probably missing something here, why does the act of "dumping" a database count as a migration? As this task is included in the clone_structure task, by running my Cucumber test suite (which requires test:clone to create the test database) I am seemingly running a migration?
Secondly, shouldn't a missing schema_migrations table be handled more elegantly than via a fatal error.
Thirdly, it would be really helpful if there was an option to ""switch off" migrations for a database that supports migrations other than by monkey patching ActiveRecord::Base.connection.supports_migrations? or hacking the Rake tasks.
I am sure I am not alone in having use cases where I don't want to use database migrations? The workaround is to ensure that I always have a schema_migrations table even if I dont use it (no biggie I guess) but this issue has just been introduced in Rails 4 as my application worked without schema_migrations under Rails 3.2
Actually dumping a database does not count as running a migration but it tries du dump the full contents of the schema_migrations table. It's part of the database structure and needs to be restored alongside.
Of course this is currently not working if you are not using migrations at all. I think we might skip this step if the schema_migrations table does not exist. There should be no harm there. I'll take a look.
only dump schema information if migration table exists. Closes #14217
@kramerdog pushed a fix to master and backported to 4-0-stable and 4-1-stable.
structure:dump works only when the schema migration table exists
See rails/rails#14217 and rsim/oracle-enhanced#440