在共享数据库设置中,为 Rails 实现简单的多租户功能。
Row-level multitenancy for Ruby on Rails apps.
This gem was born out of our own need for a fail-safe and out-of-the-way manner to add multi-tenancy to our Rails app through a shared database strategy, that integrates (near) seamless with Rails.
acts_as_tenant adds the ability to scope models to a tenant. Tenants are represented by a tenant model, such as Account. acts_as_tenant will help you set the current tenant on each request and ensures all 'tenant models' are always properly scoped to the current tenant: when viewing, searching and creating.
In addition, acts_as_tenant:
validates_uniqueness_to_tenantNote: acts_as_tenant was introduced in this blog post.
Row-level vs schema multitenancy
What's the difference?
Row-level multitenancy each model must have a tenant ID column on it. This makes it easy to filter records for each tenant using your standard database columns and indexes. ActsAsTenant uses row-level multitenancy.
Schema multitenancy uses database schemas to handle multitenancy. For this approach, your database has multiple schemas and each schema contains your database tables. Schemas require migrations to be run against each tenant and generally makes it harder to scale as you add more tenants. The Apartment gem uses schema multitenancy.
Want to see how it works? Check out the ActsAsTenant walkthrough video:
To use it, add it to your Gemfile:
gem 'acts_as_tenant'
There are two steps in adding multi-tenancy to your app with acts_as_tenant:
There are three ways to set the current tenant:
class ApplicationController < ActionController::Base
set_current_tenant_by_subdomain(:account, :subdomain)
end
This tells acts_as_tenant to use the last subdomain to identify the current tenant. In addition, it tells acts_as_tenant that tenants are represented by the Account model and this model has a column named 'subdomain' which can be used to lookup the Account using the actual subdomain. If ommitted, the parameters will default to the values used above.
By default, the last subdomain will be used for lookup. Pass in subdomain_lookup: :first to use the first subdomain instead.
class ApplicationController < ActionController::Base
set_current_tenant_by_subdomain_or_domain(:account, :subdomain, :domain)
end
You can locate the tenant using set_current_tenant_by_subdomain_or_domain( :account, :subdomain, :domain ) which will check for a subdomain and fallback to domain.
By default, the last subdomain will be used for lookup. Pass in subdomain_lookup: :first to use the first subdomain instead.
class ApplicationController < ActionController::Base
set_current_tenant_through_filter
before_action :your_method_that_finds_the_current_tenant
def your_method_that_finds_the_current_tenant
current_account = Account.find_it
set_current_tenant(current_account)
end
end
Setting the current_tenant yourself, requires you to declare set_current_tenant_through_filter at the top of your application_controller to tell acts_as_tenant that you are going to use a before_action to setup the current tenant. Next you should actually setup that before_action to fetch the current tenant and pass it to acts_as_tenant by using set_current_tenant(current_tenant) in the before_action.
If you are setting the tenant in a specific controller (except application_controller), it should to be included AT THE TOP of the file.
class MembersController < ActionController::Base
set_current_tenant_through_filter
before_action :set_tenant
before_action :set_member, only: [:show, :edit, :update, :destroy]
def set_tenant
set_current_tenant(current_user.account)
end
end
This allows the tenant to be set before any other code runs so everything is within the current tenant.
ActsAsTenant.with_tenant(current_account) do
# Current tenant is set for all code in this block
end
This approach is useful when running background processes for a specified tenant. For example, by putting this in your worker's run method, any code in this block will be scoped to the current tenant. All methods that set the current tenant are thread safe.
Note: If the current tenant is not set by one of these methods, Acts_as_tenant will be unable to apply the proper scope to your models. So make sure you use one of the two methods to tell acts_as_tenant about the current tenant.
ActsAsTenant.without_tenant do
# Tenant checking is disabled for all code in this block
end
This is useful in shared routes such as admin panels or internal dashboards when require_tenant option is enabled throughout the app.
ActsAsTenant.with_mutable_tenant do
# Tenant updating is enabled for all code in this block
end
This will allow you to change the tenant of a model. This feature is useful for admin screens, where it is ok to allow certain users to change the tenant on existing models in specific cases.
If you want to require the tenant to be set at all times, you can configure acts_as_tenant to raise an error when a query is made without a tenant available. See below under configuration options.
class AddAccountToProjects < ActiveRecord::Migration
def up
add_column :projects, :account_id, :integer
add_index :projects, :account_id
end
end
class Project < ActiveRecord::Base
acts_as_tenant(:account)
end
acts_as_tenant requires each scoped model to have a column in its schema linking it to a tenant. Adding acts_as_tenant to your model declaration will scope that model to the current tenant BUT ONLY if a current tenant has been set.
Some examples to illustrate this behavior:
…
Acts_as_tenant uses Rails' default_scope method to scope models. Rails 3.1 changed the way default_scope works in a good way. A user defined default_scope should integrate seamlessly with the one added by acts_as_tenant.
You should call acts_as_tenant after any belongs_to associations in your model.
If you need to validate for uniqueness, chances are that you want to scope this validation to a tenant. You can do so by using:
validates_uniqueness_to_tenant :name, :email
All options available to Rails' own validates_uniqueness_of are also available to this method.
You can explicitly specifiy a foreign_key for AaT to use should the key differ from the default:
acts_as_tenant(:account, :foreign_key => 'accountID') # by default AaT expects account_id
You can also explicitly specifiy a primary_key for AaT to use should the key differ from the default:
acts_as_tenant(:account, :primary_key => 'primaryID') # by default AaT expects id
You can scope a model that is part of a HABTM relationship by using the through option.
class Organisation < ActiveRecord::Base
has_many :organisations_users
has_many :users, through: :organisations_users
end
class User < ActiveRecord::Base
has_many :organisations_users
acts_as_tenant :organisation, through: :organisations_users
end
class OrganisationsUser < ActiveRecord::Base
belongs_to :user
acts_as_tenant :organisation
end
An initializer can be created to control (currently one) option in ActsAsTenant. Defaults
are shown below with sample overrides following. In config/initializers/acts_as_tenant.rb:
ActsAsTenant.configure do |config|
config.require_tenant = false # true
# Customize the query for loading the tenant in background jobs
config.job_scope = ->{ all }
end
config.require_tenant when set to true will raise an ActsAsTenant::NoTenant error whenever a query is made without a tenant set.config.require_tenant can also be assigned a lambda that is evaluated at run time. For example:
ActsAsTenant.configure do |config|
config.require_tenant = lambda do
if $request_env.present?
return false if $request_env["REQUEST_PATH"].start_with?("/admin/")
end
return true
end
end
The lambda can also optionally receive the ar_relation currently being evaluated as an argument. This is useful for finer control over tenant requirements.
For example, if you wanted to require the tenant for every model except User, you could do the following:
ActsAsTenant.configure do |config|
config.require_tenant = lambda do |relation|
relation.klass.name != "User"
end
end
ActsAsTenant.should_require_tenant? is used to determine if a tenant is required in the current context, either by evaluating the lambda provided, or by returning the boolean value assigned to config.require_tenant.
When using config.require_tenant alongside the rails console, a nice quality of life tweak is to set the tenant in the console session in your initializer script. For example in config/initializers/acts_as_tenant.rb:
Rails.application.configure do
if Rails.env.development? && defined?(Rails::Console)
# set the current_tenant during console startup and after calling reload!
# note: reload! calls the to_prepare callback twice
ActiveSupport::Reloader.to_prepare do
puts ">>> Setting ActsAsTenant.current_tenant = Account.first"
ActsAsTenant.current_tenant = Account.first
end
end
end
acts_as_tenant :account includes the belongs_to relationship.
So when using acts_as_tenant on a model, do not add belongs_to :account alongside acts_as_tenant :account:
class User < ActiveRecord::Base
acts_as_tenant(:account) # YES
belongs_to :account # REDUNDANT
end
You can add the following belongs_to options to acts_as_tenant:
:foreign_key, :class_name, :inverse_of, :optional, :primary_key, :counter_cache, :polymorphic, :touch
Example: acts_as_tenant(:account, counter_cache: true)
ActsAsTenant supports
ActiveJob - ActsAsTenant will automatically save the current tenant in ActiveJob arguments and set it when the job runs.
Sidekiq
Add the following code to config/initializers/acts_as_tenant.rb:
require 'acts_as_tenant/sidekiq'
If you set the current_tenant in your tests, make sure to clean up the tenant after each test by calling ActsAsTenant.current_tenant = nil. Integration tests are more difficult: manually setting the current_tenant value will not survive across multiple requests, even if they take place within the
暂无开放 Issues，或尚未同步最近议题。