New Post: Multi-Schema support for migrations (to support multi-tenancy for SaaS for example)

Hi folks,

I am very interested in support for multiple database schemas with migrations. My concrete requirement is to use migrations to manage the same data model within a database for many tenants which I want to separate by database schema. Say we have a data model with one entity called TheEntity. Furthermore lets say whe have two tenants identified by a GUID (00000000-0000-0000-0000-000000000001, 0x1 for short and 00000000-0000-0000-0000-000000000002, 0x2 for short). I want to run the code based migrations by using the DbMigrator class and the tables should be created as follows:

  0x1.__MigrationHistory
  0x1.TheEntity

  0x2.__MigrationHistory
  0x2.TheEntity

I have worked through much of the entity framework and migrations code the last two days to check what could work right now and to be honest for me the handling of schemas within the migrations code seems to be a bit over complicated but maybe I do not get the benefit of the complexity and the necessity of it. But back to my concern:

• I have a class called SqlServerSchemaAwareMigrationSqlGenerator which inherits from SqlServerMigrationSqlGenerator. This class overrides the method Generate(CreateTableOperation createTableOperation) to replace the table name of the incomming CreateTableOperation. My implementation replaces "dbo.[table-name]" with "[tenant-id].[table-name]". Not a nice solution but thereby I achieve my goal to get the tables created in an own schema.
  
• Next I set a HistoryContextFactory on the DbMigrationsConfiguration to set the schema of the HistoryContext.
  

I tried using the class DbMigrator. The first execution throws an _SqlException "Invalid object name '00000000-0000-0000-0000-000000000001._MigrationHistory'." which is wrapped into an EntityCommandExecutionException which gets catched within HistoryRepository.QueryExists(...). The DbMigrator checks if the history table exists by catching EntityException??? Isn't that a bad pattern? The next problem appears on all following update processes. There is some code in HistoryRepository.GetUpgradeOperations() which handles some legacy stuff (keyword LegacyHistoryContext). The problem is that the code hardcodes the name of the history table as follows:

  const string tableName = "dbo." + HistoryContext.DefaultTableName;

Hardcoded "dbo"? What the heck?

Well, to be perfectly honest I realized that both exceptions are handled by the HistoryRepository while writing this posting but am I right that the schema stuff in the migration code is suboptimal?

My SqlServerSchemaAwareMigrationSqlGenerator class is a bad and not very general solution I know. Are there any plans to support something like my scenario in the future? I know there are some demands on such features on stack overflow for example to make migrations suitable for multi-tenand-SaaS-solutions.

Best regards from germany,

Tobias Jamin

PS: Maybe another topic with the name migrations could be usefull to tag a discussion like this one.