If a model needs to span schemas, it's usually easier to keep that model in the public schema or move it out to public if it's already namespaced. Then we just use the multitenancy strategy outlined in the previous video for those cases. It's possible to do both forms of multitenancy in a single app and having that flexibility is helpful. Also, we use apartment, which makes it easy to exclude models from being namespaced.
We use the apartment gem referenced at the end, which has been working great for us.
One feature that's particularly useful is that it has a way to provide a list of tables which should be be namespaced. So you would add Account or Tenant to that list, which saves you from having to remember which migrations need the extra check to see if the table exists.
We don't use subdomain either. We store the current schema on the user and set the schema to that user's schema on every request made by that user.
I wonder how easy it would be to use this with Apartment. Apartment currently supports DJ. Also, it would be cool to see an episode on Apartment. It'd fit right into the current Postgres theme.
If a model needs to span schemas, it's usually easier to keep that model in the public schema or move it out to public if it's already namespaced. Then we just use the multitenancy strategy outlined in the previous video for those cases. It's possible to do both forms of multitenancy in a single app and having that flexibility is helpful. Also, we use apartment, which makes it easy to exclude models from being namespaced.
We use the apartment gem referenced at the end, which has been working great for us.
I wonder how easy it would be to use this with Apartment. Apartment currently supports DJ. Also, it would be cool to see an episode on Apartment. It'd fit right into the current Postgres theme.