3

I tried following through the source code and the docs, but after a lost morning I give up: at the same time it's as if not enough assumptions are made in the SchemaDumper and at the same time there's no SchemaLoader and following through the sequel command source code it seems that it clobbers migration information to-date (since it has no "migrations to date" kind of information in the resulting file).

The motivation to do this is a failed migration in tests (Sequel thinks the tables are not there, yet they are so it breaks both on migrating to new versions and the check pending migrations check fails) - and a previous experience that running all migrations from start of history to today is generally a bad way to put up a database.

I've got this thus far:

namespace :schema do

  task :dump => :migrations_environment do
    schema = without_sequel_logging{ DB.dump_schema_migration }
    File.open("db/schema.rb", 'w') {|f| f.write(schema) }
  end

  task :load => :migrations_environment do
    Sequel::Migrator.run(DB, "db/schema.rb")
  end

end

normally the load fails since the Migrator makes a load of assumptions ranging starting from that it will be given a folder full of files in a specific order, yet this is apparently exactly what sequel -m and sequel -d should do according to current source code - and sequel -m and sequel -d combo are apparently what you should use when you want to do schema dump & schema load.

Any ideas?

bbozo
  • 7,075
  • 3
  • 30
  • 56

1 Answers1

2

I think you are misunderstanding the point of Sequel's schema dump and load. Schema dumping should only be used if you have an existing database and would like to produce a migration from it, either for review of what tables/columns exist, or for loading into an empty database. Loading a migration dumped by the schema dumper should only be done on an empty database.

If you already have an existing test database that is not empty (i.e. previous migrations have been applied to it), you shouldn't be using schema dump and load, you should just run the migrator on the test database. In general, it's best to migrate your test database before you migrate your development database, so you can then run your tests and see if the migration breaks anything.

The only time you should have to run all migrations since the beginning is if you have an empty database. If you migrate your test databases similar to the way you migrate your development and production databases, you are generally only applying a single migration at a time.

Note that the schema dumper only handles a small fraction of what is possible, and will only work correctly for the simplest cases. It doesn't handle dumping views, functions, triggers, partial/functional indexes, and a whole range of other things. For all but the simplest cases, use the database's tools to dump and load schema.

Jeremy Evans
  • 11,959
  • 27
  • 26