Hardecoded schema.rb #1

rurounijones opened this Issue Oct 3, 2012 · 7 comments

5 participants


In the AbstractAdapter.import_database_schema method it is looking for a hardcoded db/schema.rb file.

However it is possible that this file does not exist (If the rails config.active_record.schema_format = :sql is used which will be very common when using hstore and hstore related indexes) and that the associated structure.sql file should be used instead to load the schema.

This issue has been copied from the old repo.
If I find the time in the near future I will see if I can fix it but do not hold your breath.


Even if it wasn't looking for a hardcoded schema.rb file, schema.sql doesn't work, as the Rails dumper doesn't play too well with multiple schemas the last time I tried it. It's probably fixable, but it would involve some modifications of some rake tasks, particularly db:schema:dump and db:schema:load. If you want to take a look, we'd welcome a pull request - we use hstore as well and have a few workarounds to get around being unable to dump a sql schema.


Do you have the workaround documented anywhere? I am not sure i will have time to fix this for a while so it may come in useful.


Also I'd like to notice that using schema.rb doesn't solve the problem if the database has complex structure with triggers and functions. These are just silently ommited in the schema.rb

As a workaround it might be possible to run all the migrations against the new schema on create instead...
Yes, it might take much longer then loading schema.rb, but it should preserve the DB code.
So it would be great to have such an option.

Influitive Corporation member

i dont' think we'd recommend this type of behaviour. Migrations are not meant to be the definitive source for your db, the schema is. Migrations become unreliable on larger projects as refactorings take place. They're not even guaranteed to run start to end at that point. We often clean up our migration directory as it piles up.

Yes we're limited with schema.rb. We'll have to discuss some solutions for supporting things like contraints that may be added through migrations.


Generating and using db/structure.sql can help, but I don't know if it can be easily applied to some specified schema other then the one used at the dump time. I finally used the split-migration approach applying the tenant part of the migrations with ActiveRecord::Migrator every time a tenant gets created or needs a schema update.


I think I just read in the latest 3.2.14 release that they've fixed the dumping?

Influitive Corporation member

Ya I guess you're referring to this in the changelog:

Resets the postgres search path in the structure.sql after the structure is dumped in order to find schema_migrations table when multiples schemas are used. Fixes #9796.

Might be worth a look into it. We could probably allow a config option for the dump type (ie :sql, or :ruby) or something to that affect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment