multi-tenant

I would like to ask your opinions regarding the way I handle MultiTenancy. I"m using MVC3 (switching to MVC4) and EF as my backend. I'm using a single app, shared schema MultiTenancy. Below is the code: public abstract class Service<T> where T : Entity { private Repository<T> _repo; public Service() { _repo = new Repository<T>(); } public bool Authenticate(int id) { //var companyInfo = _authorizationRepository.GetApiKey(apiKey); int tenantId = 0; // replaced by companyInfo using repository var entity = _repo.GetQuery(tenantId).Where(e => e.Id == id).First(); if (tenantId != entity.TenantId)

Tenants in eclipselink (or Hibernate) are a great concept to separate data domains from each other. I am using eclipselink with single-table strategy. Sometimes it is necessary to access data from more than just one tenant (e.g. for admin purposes). Is there a good way to achieve that? (I do not want to run through all tenants to collect the data...) Example: @Entity @Multitenant @TenantDiscriminatorColumn(name = "TENANT", contextProperty = "tenant.id") public class TenantEntity { ... I can access the objects in a specific tenant with a parameterized entity manager: private static

I am organizing a multi tenant application with a single code base/application using subdomains to detect the tenant, then runs a SET SCHEMA on postgres to do the fun stuff. My issue is that certain clients will require various levels of customization to the main codebase. Not a ton, but certainly enough to the point that I wouldn't want to start hacking the main models and controllers by adding a bunch of if statements. Overriding views is easy enough with views load paths... but my question is: How can I provide a good framework for overriding or adding functionality to the base controllers,

We are planning to use Azure Service Fabric for a data-oriented multi-tenant application. Typically 100+ customers each with 5 - 100 users. Looking at the documentation, I concluded that the best approach is to use an Application instance for each customer, rather than trying to use Profiles to achieve multi-tenancy. Is this the best way to go ? An application instance for each customer is a good way to handle multi-tenant situations on a single cluster, yes. There are Service Fabric applications that do this today (Azure DB is a notable one). Here are some things you get with this approach:

I have the following data structure: //property Notification abstract class BindableBase { } //base class for all tenant-scoped objects abstract class TenantModelBase : BindableBase { int TenantId; } abstract class Order : TenantModelBase { Customer Customer; //works: mapped using TenantId and CustomerId Product Product; //again, works with TenantId and ProductId string ProductId; string CustomerId; } class Customer: TenantModelBase { string CustomerId; } class Product : TenantModelBase { string ProductId; } class SpecialOrder : Order { OtherClass OtherClass; //this fails!, see below string

In my app every user has its own database that created when user registered. Connection and database data (database name, username, password) are saved in a table in default database. try{ DB::transaction(function() { $website = new Website(); $website->user_id = Auth::get()->id; $website->save(); $database_name = 'website_'.$website->id; DB::statement(DB::raw('CREATE DATABASE ' . $database_name)); $websiteDatabase = new WebsiteDatabase(); $websiteDatabase->website_id = $website->id; $websiteDatabase->database_name = $database_name; $websiteDatabase->save(); }); } catch(\Exception $e) { echo

I am trying to get Spring-Data JPA working with Hibernate with a custom MultiTenantConnectionProvider. Everything in my configuration below seems to work. My MultiTenantConnectionProviderImpl class gets called each time I try to call a Repository method. The main problem is that there is no way to provide a tenant identifier. The Repository interfaces provided by Spring-Data take care of getting the Hibernate Session. Is there any way to provide Spring-Data the tenant identifier? Or is there somewhere where we can intercept the creation of the Hibernate Session so we can appropriately call