c483c6036a
This way all tenants will be able to access them instead of just the default one. The apartment gem recommends using a rake task instead of a migration, but that's a solution which is primarily meant for new installations. Migrations are easier to execute on existing installations. However, since this migration doesn't affect the `schema.rb` file, we still need to make sure the shared schema is created in tasks which do not execute migrations, like `db:schema:load` or `db:test:prepare`, just like the apartment gem recommends. That's why we're enhancing these tasks so they execute this migration. Note that there might be cases where the database user isn't a superuser (as it's usually the case on production environments), meaning commands to create, alter or drop extensions will fail. There's also the case where users don't have permissions to create schemas, which is needed in order to create the shared extensions schema and the schemas used by the tenants. For these reasons, we're minimizing the number of commands, and so we only alter or create extensions when it is really necessary. When users don't have permission, we aren't running the commands but showing a warning with the steps needed to run the migration manually. This is only necessary on installations which are going to use multitenancy; single-tenant applications upgrading don't need to run this migration, and that's why we aren't raising exceptions when we can't run it. For new installations, we'll change the CONSUL installer so extensions are automatically created in the shared schema. Also note the plpgsql extension is not handled here. This is a special extension which must be installed on the pg_catalog schema, which is always in the search path and so is shared by all tenants. Finally, we also need to change the `database.yml` file in order to search for shared extensions while running migrations or model tests, since none of our enabled extensions are executed during migrations; we're also adding a rake task for existing installations. Quoting the apartment documentation: > your database.yml file must mimic what you've set for your default and > persistent schemas in Apartment. When you run migrations with Rails, > it won't know about the extensions schema because Apartment isn't > injected into the default connection, it's done on a per-request > basis.
118 lines
4.9 KiB
Ruby
118 lines
4.9 KiB
Ruby
# You can have Apartment route to the appropriate Tenant by adding some Rack middleware.
|
|
# Apartment can support many different "Elevators" that can take care of this routing to your data.
|
|
# Require whichever Elevator you're using below or none if you have a custom one.
|
|
#
|
|
# require "apartment/elevators/generic"
|
|
# require "apartment/elevators/domain"
|
|
require "apartment/elevators/subdomain"
|
|
# require "apartment/elevators/first_subdomain"
|
|
# require "apartment/elevators/host"
|
|
|
|
#
|
|
# Apartment Configuration
|
|
#
|
|
Apartment.configure do |config|
|
|
config.seed_after_create = true
|
|
|
|
# Add any models that you do not want to be multi-tenanted, but remain in the global (public) namespace.
|
|
# A typical example would be a Customer or Tenant model that stores each Tenant's information.
|
|
#
|
|
config.excluded_models = %w[Tenant]
|
|
|
|
# In order to migrate all of your Tenants you need to provide a list of Tenant names to Apartment.
|
|
# You can make this dynamic by providing a Proc object to be called on migrations.
|
|
# This object should yield either:
|
|
# - an array of strings representing each Tenant name.
|
|
# - a hash which keys are tenant names, and values custom db config
|
|
# (must contain all key/values required in database.yml)
|
|
#
|
|
# config.tenant_names = lambda{ Customer.pluck(:tenant_name) }
|
|
# config.tenant_names = ["tenant1", "tenant2"]
|
|
# config.tenant_names = {
|
|
# "tenant1" => {
|
|
# adapter: "postgresql",
|
|
# host: "some_server",
|
|
# port: 5555,
|
|
# database: "postgres" # this is not the name of the tenant's db
|
|
# # but the name of the database to connect to before creating the tenant's db
|
|
# # mandatory in postgresql
|
|
# },
|
|
# "tenant2" => {
|
|
# adapter: "postgresql",
|
|
# database: "postgres" # this is not the name of the tenant's db
|
|
# # but the name of the database to connect to before creating the tenant's db
|
|
# # mandatory in postgresql
|
|
# }
|
|
# }
|
|
# config.tenant_names = lambda do
|
|
# Tenant.all.each_with_object({}) do |tenant, hash|
|
|
# hash[tenant.name] = tenant.db_configuration
|
|
# end
|
|
# end
|
|
#
|
|
config.tenant_names = -> { Tenant.pluck :schema }
|
|
|
|
# PostgreSQL:
|
|
# Specifies whether to use PostgreSQL schemas or create a new database per Tenant.
|
|
#
|
|
# MySQL:
|
|
# Specifies whether to switch databases by using `use` statement or re-establish connection.
|
|
#
|
|
# The default behaviour is true.
|
|
#
|
|
# config.use_schemas = true
|
|
|
|
#
|
|
# ==> PostgreSQL only options
|
|
|
|
# Apartment can be forced to use raw SQL dumps instead of schema.rb for creating new schemas.
|
|
# Use this when you are using some extra features in PostgreSQL that can't be represented in
|
|
# schema.rb, like materialized views etc. (only applies with use_schemas set to true).
|
|
# (Note: this option doesn't use db/structure.sql, it creates SQL dump by executing pg_dump)
|
|
#
|
|
# config.use_sql = false
|
|
|
|
# There are cases where you might want some schemas to always be in your search_path
|
|
# e.g when using a PostgreSQL extension like hstore.
|
|
# Any schemas added here will be available along with your selected Tenant.
|
|
#
|
|
config.persistent_schemas = ["shared_extensions"]
|
|
|
|
# <== PostgreSQL only options
|
|
#
|
|
|
|
# By default, and only when not using PostgreSQL schemas, Apartment will prepend the environment
|
|
# to the tenant name to ensure there is no conflict between your environments.
|
|
# This is mainly for the benefit of your development and test environments.
|
|
# Uncomment the line below if you want to disable this behaviour in production.
|
|
#
|
|
# config.prepend_environment = !Rails.env.production?
|
|
|
|
# When using PostgreSQL schemas, the database dump will be namespaced, and
|
|
# apartment will substitute the default namespace (usually public) with the
|
|
# name of the new tenant when creating a new tenant. Some items must maintain
|
|
# a reference to the default namespace (ie public) - for instance, a default
|
|
# uuid generation. Uncomment the line below to create a list of namespaced
|
|
# items in the schema dump that should *not* have their namespace replaced by
|
|
# the new tenant
|
|
#
|
|
# config.pg_excluded_names = ["uuid_generate_v4"]
|
|
|
|
# Specifies whether the database and schema (when using PostgreSQL schemas) will prepend in ActiveRecord log.
|
|
# Uncomment the line below if you want to enable this behavior.
|
|
#
|
|
# config.active_record_log = true
|
|
end
|
|
|
|
# Setup a custom Tenant switching middleware. The Proc should return the name of the Tenant that
|
|
# you want to switch to.
|
|
# Rails.application.config.middleware.use Apartment::Elevators::Generic, lambda { |request|
|
|
# request.host.split(".").first
|
|
# }
|
|
|
|
# Rails.application.config.middleware.use Apartment::Elevators::Domain
|
|
Rails.application.config.middleware.use Apartment::Elevators::Subdomain
|
|
# Rails.application.config.middleware.use Apartment::Elevators::FirstSubdomain
|
|
# Rails.application.config.middleware.use Apartment::Elevators::Host
|
|
Apartment::Elevators::Subdomain.excluded_subdomains = %w[public www]
|