#388 Multitenancy with Scopes pro

+1 for testing... if not talk about it, include some example tests in the episode source code!

+1 for TESTS!!! I found this to be quite hard to test. The complexity grows when you have an authentication system on top of the subdomains.

+1 for tests!

In this blog (http://railscraft.tumblr.com/post/21403448184/multi-tenanting-ruby-on-rails-applications-on-heroku) the author recommends rows based multitenancy over schema based and gives the following pros and cons:

Summary of ROW-BASED Pros & Cons

Pros:

simpler implementation
ability to use existing rails migration tools
use of Postgres Views/Rules & Rails 3 scope to enforce
faster pg_dump, typical use case optimization in DB parser/planner for SELECT QUERIES
no need to jerry-rig IDs
no monkey-patching of Rails A/R (maybe just the connection)

Cons:
might break down at 20 to 50M records in a single table?
difficulty in partitioning?

I don't think you can argue that something that switched DBs is less prone to error and attack than something that is query-based... I prefer it, personally, and have used it for many years.

See my comment above about testing where i mention why I changed... TLDR: The app grew and many DBs became an overhead we could not afford.

I should also note that it was not a huge thing for me to add a default scope (in a module btw) and including that in all models. Then it was just a matter of setting the right tenant association on existing data before migrating it all to a single DB. The testing was probably what I spent the longest on.

I figured it out. Stupidly, my yield was inside of my if condition!

You can also make use of routes.rb to perform something similar to this and most sub domain setup work.

  # Subdomain handling via route constraint
  constraints(Domain) do
    # Regular routes that scope on subdomains go in here
  end
  # Routes to use if no tenant subdomain exists

In the above example Domain is a class with a method named matches? in it. More about making use of this trigger (which is very early in the request process) to setup the tenant stuff is found in the rails guides starting here:
http://guides.rubyonrails.org/routing.html#request-based-constraints

We trigger all subdomain/tenant setup from this kind of route constraint.

Agree! And one other point we learned the hard way: we had used subdomains for environments for testing and staging (e.g. tenant1.staging.example.com) and didn't realized until too late that wildcard domains only give you one level of subdomain. A better strategy is to do something like tenant1-staging.example.com.

Bump

Same question: Can this approach be used for deploying a rails app configured for multiple root domains (e.g. domain1.com and domain2.com)?

If so, what changes would be required to make it work? I'm thinking about things like routing.

Thanks

It's not really all that different than what Ryan shows in this episode, or perhaps not at all -- there's something in the request that identifies which tenant is current (the current_tenant method, for example), and there's some sort of table that contains details about the tenant.

You can decide how you want to set up your web server -- you might set up a virtual host for each domain, or in the case of a small number, a single vhost that handles all domains (e.g. using Apache's ServerAlias directive). While it's also possible to let all requests through on the default host (sometimes called the "catch all host") and handle the ones you know, I prefer having a more declarative setup.

I also recommend having some sort of immutable unique text key (all lowercase, single word) that you use to identify the tenant in the database. Once you do that, you can use it as a kind of namespace that allows your app to pick up tenant-specific CSS selectors, locations for assets like logos, and so on.

Remington,

have you found a solution?

I am just creating an admin user in create_schema method of tenant. Since admin table is there in every schema, you end up with schema (or tenant) specif admin(s). This is not too bad if you want to distribute the admin work to a team of support persons and distribute the load based on accounts/regions.

However, if you prefer to have one admin table for all schemas, then leave it in public and drop from tenant schema when you create a new tenant.

In the earlier part of the episode, Ryan used a cattr_accessor which is a Rails shortcut for creating class methods.

(I think this is right, but anyone who knows better, please correct!) The reason to consider thread safety is that unlike instance variables, class methods are considered "static". Depending on how you have Rails deployed in a production environment this is not inherently thread-safe -- Ryan did a recent RailsCast on thread safety that explains more, but the short answer is whether or not something will be thread-safe depends on an external configuration that might change with a new version, or work differently in a few months, etc.

For me, at least, that's reason enough to add this little bit of safety.

I don't have a solid answer on the use of the instance variable, but I think it boils down to this: is @tenant_id that you reference at one moment necessarily the one you reference at another, or is it one on another thread? Again, the fact that this is a class method, not an instance method is what makes the difference.

(And if my explanation is wrong, I do hope someone can correct me so we all understand :-)

It is the user that create/read/update/delete the tenant, not the other way around, so he can have multiple tenants. And in theory, a user can exist without any tenant if you desire so. You just need to implement a role based authorization system in your app.

App wide super-admin can be implemented as a kind of super user that has access to all tenants, but it's better to have it's own class so you can also assign different roles to it.

actually they are not nil they lose values