2015-12-07 3 views
1

Мы пытаемся использовать CFE для создания одной схемы для каждого арендатора, как указано в сообщении блога CodeFluent (http://blog.codefluententities.com/2014/12/04/multi-tenant-using-multiple-schema/). В этом случае мы ожидаем, что каждая сгенерированная схема должна быть идентичной, и мы используем систему ICodeFluentPersistence Hook для идентификации компании для пользователя, а затем правильно настроим схему, которая будет использоваться. Все это работает нормально, но когда мы запускаем код для генерации нескольких схем (https://github.com/SoftFluent/CodeFluent-Entities/tree/master/Extensions/SoftFluent.MultiTenantGenerator), он удаляет ограничения. Затем я попытался выяснить, была ли проблема с моей конфигурацией, но запуск примера программы из GitHub дает те же результаты. После запуска программы-примера основной ключ не присутствовал в схеме contoso, хотя он был правильно определен в схеме dbo (и в модели).Проблема с генератором схемы многопользовательской схемы

Results after generating schema

Кто-нибудь использовал генератор Multi-схемы CFE или иметь представление о том, что проблема может быть?

ответ

0

Генератор с несколькими схемами загружает модель и динамически изменяет ее для изменения схемы объектов. Затем он вызывает процесс создания стандартного кода только с производителями баз данных (SQL Server, Oracle и т. Д.).

Так что, если вы хотите создать 2 Differents схемы (ДБО и компании Contoso) против пустой базы данных, процесс выглядит следующим образом:

  1. Сформировать базу данных для схемы ДБО от пустой базы данных
  2. Генерация база данных для схемы contoso из ранее сгенерированной базы данных

Перед созданием ограничения механизм SQL Server diff отключает ограничение с тем же именем. На самом деле SQL Server не позволяет двум ограничениям иметь одно и то же имя (я не могу найти страницу в MSDN с более подробной информацией об этом). Таким образом, в вашем случае существующий PK отбрасывается при создании схемы contoso, потому что имя PK совпадает с именем, которое существует в схеме dbo. Может быть, это может быть улучшено, но дифференциалы двигатель пытается генерировать код, который работает для SQL Server 2000 на SQL Server 2016.

обходные пути

Вы можете создавать каждую схему в другой базе данных, так и переформатирование двигатель будет генерировать код, который вы ожидаете. Затем вы можете запускать сгенерированные скрипты в производственной базе данных. Не самый простой способ, но он должен работать.

Вы можете использовать производителя патча, чтобы заменить имя схемы в файле. Для SQL-файлов вы должны использовать SqlServerPatchProducer, как поясняют в KnowledgeBase:

namespace Sample 
{ 
    public class SqlServerPatchProducer : SqlServerProducer 
    { 
     public SqlServerPatchProducer() 
     { 
     } 

     protected override void RunProceduresScript() 
     { 
      string path = GetPath(Project.DefaultNamespace + "_procedures.sql"); 
      ProduceFrom(path, "before"); 
      SearchAndReplaceProducer.ProducePatches(Project, null, this, null, ProductionFlags, Element); 
      Utilities.RunFileScript(path, Database, OutputEncoding); 
      ProduceFrom(path, "after"); 
     } 
    } 
} 
+0

У вас есть возможность взглянуть на ответ выше? Неужели я полностью оторван от базы? – user2589758

+0

Я добавляю 2 обходных пути в ответ – meziantou

0

Спасибо за ваш ответ, но я не уверен, что я согласен. Целая причина (по крайней мере, мне) использовать генератор Multi-Tenant - создать как можно больше схем базы данных (по одному на каждого клиента) из одной модели ДОВСЕ.Идея о том, что вы потеряете ограничения во всех, кроме одного из них, не чувствовала себя правильно, поэтому я сделал еще несколько исследований и нашел следующее в «Microsoft SQL Server 2012 Internals» Кален Делани и Крейг Фримен (через Google Книги): enter image description here

И в самом деле был в состоянии сделать быстрый тест, чтобы доказать это путем создания двух идентичных таблиц с одинаковыми именами PK:

enter image description here

Так что, казалось бы мне, что CFE должен быть в состоянии для создания двух идентичных баз данных из той же модели и, как представляется, указывает на недостаток механизма SQLServer diff.

Смежные вопросы