Fully separate schema: common vs tenant

[mjsteckel]

Consider this a proof of concept and not a formal pull request. I am sure that there are cleaner ways of accomplishing the functionality that I've implemented.

1. maintain separation between "common" and tenant schemas (means that "common" tables are not also in the tenant schema!)
2. tasks to process all tenants or a single tenant
3. supports migrations for all tenants plus per tenant migrations (potentially scary)
4. changed default so that db:migrate does NOT run apartment migrations.

There is work left to do to clean things up, for instance apartment:load is missing. Also, tests haven't been updated.

[bradrobertson]

I'm pretty sure the previous impl, where one takes the AR migration_paths is so that engines that provide migrations could also be run. I didn't implement it, it was a PR, but I'm pretty sure this would revert that change. @linki can you comment?

[bradrobertson]

I don't actually see any indication of splitting out the public schema from the tenanted schemas. It's definitely something I'd like to achieve, just haven't had the time to implement it.

Things to think about:

1. schema.rb is generated from the default schema_search_path in Postgres, which by default is public. So, we'd need that schema to have all the tables we want in schema.rb. I've thought about possibly having an _apartment_excluded_models schema strictly for excluded models, then a separate schema (maybe _apartment_schema_rb?) that rails would use to generate the schema.rb file from.
2. Having public in the schema_search_path (ie a persistent_schema) at all times will NOT work until we can properly separate the excluded models schema from the tenanted schema as you mentioned previously due to issues generating schema.rb. It's definitely a limitation at the moment.