Изменение схемы базы данных инфраструктуры Entity во время выполнения
В большинстве приложений asp.net вы можете изменить хранилище базы данных, изменив строку соединения во время выполнения. i.e Я могу перейти от использования тестовой базы данных к производственной базе данных, просто изменив значение поля базы данных в строке соединения
Я пытаюсь изменить схему (но не обязательно сама база данных) с инфраструктурой сущностей, но не повезло.
Проблема, которую я вижу, заключается в том, что содержимое SSDL в XML файле edmx хранит схему для каждого набора объектов.
см. ниже
<EntitySet
Name="task"
EntityType="hardModel.Store.task"
store:Type="Tables"
Schema="test" />
Теперь я изменил значение атрибута схемы на "prod" из теста, и он работает.
Но это не кажется хорошим решением.
- Мне нужно обновить evert entity set, а также хранимые процедуры (у меня есть +50 таблиц)
- Я могу сделать это только время компиляции?
- Если я затем попытаюсь позже обновить сущности Entity, которые уже существуют, считываются из-за того, что EF не распознает, что таблица уже существует в edm.
Любые мысли?
Ответы
Ответ 1
Обновить. При чтении комментариев выясняется, что вы хотите изменить ссылочную схему для каждого БД, а не базы данных. Я отредактировал вопрос, чтобы уточнить это и восстановить образец EDMX, который вы предоставили, который был скрыт в исходном форматировании.
Я повторю свой комментарий ниже:
Если схемы находятся в одной и той же БД, вы не можете переключать их во время выполнения (за исключением только кода EF 4). Это связано с тем, что две одинаково названные и структурированные таблицы в двух разных схемах считаются полностью разными таблицами.
Я также согласен с JMarsch выше: я бы пересмотрел дизайн ввода тестовых и производственных данных (или, фактически, "ничего и производственных данных" ) в одну и ту же БД. Похоже на приглашение к катастрофе.
Старый ответ ниже.
Вы уверены, что измените правильную строку соединения? Строка соединения, используемая EF, встроена в строку соединения, которая указывает местоположение CSDL/SSDL/etc. Обычно имеет "нормальную" строку подключения для использования какой-либо другой частью вашего приложения (например, членство в ASP.NET). В этом случае при изменении БД вы должны обновить и своих строк подключения.
Аналогично, если вы обновляете строку подключения во время выполнения, вы должны использовать специальные инструменты для этого, которые понимают формат строки подключения EF и являются отдельными от обычного построителя строк соединений. См. Пример в ссылке. См. Также эту помощь при назначении строк подключения EF.
Ответ 2
У меня есть эта же проблема, и это действительно довольно раздражает, потому что это один из тех случаев, когда Microsoft действительно пропустила лодку. Половина причины использования EF - это поддержка дополнительных баз данных, но если вы сначала не запустите код, который на самом деле не устранит проблему.
В MS SQL изменение схемы имеет мало смысла, потому что схема является частью идентификатора таблиц. Для других типов баз данных схема очень не является частью идентификатора базы данных и определяет местоположение базы данных. Подключение к Oracle и изменение базы данных и изменение схемы по существу являются синонимами.
Ответ 3
Извините, что это не надежный ответ, но я нашел этот проект на codeplex (а также этот вопрос) во время поиска по аналогичной проблеме:
http://efmodeladapter.codeplex.com/
Возможности включают:
- Временная настройка схемы модели,
в том числе:
- Настройка таблицы уровня данных
префиксы или суффиксы
- Настройка
владелец объектов базы данных
Некоторые коды из документов:
public partial class MyObjectContext : BrandonHaynes.ModelAdapter.EntityFramework.AdaptingObjectContext
{
public MyObjectContext()
: base(myConnectionString,
new ConnectionAdapter(
new TablePrefixModelAdapter("Prefix",
new TableSuffixModelAdapter("Suffix")),
System.Reflection.Assembly.GetCallingAssembly()))
{
...
}
}
Похоже на то, что вы ищете.
Ответ 4
Строка подключения для EF находится в файле конфигурации. Нет необходимости изменять файл SSDL.
ИЗМЕНИТЬ
Есть ли у вас схема prod и test в той же базе данных?
Если да, вы можете исправить это, используя отдельную базу данных для prod и test. Использование одного и того же имени схемы в обеих базах данных.
Если "Нет", вы можете исправить это, используя одно и то же имя схемы в обеих базах данных.
Если у вас будут абсолютные имена разных схем, создайте две модели EF, одну для теста и одну для prod, а затем выберите, какой из них использовать в коде на основе значения в вашем файле конфигурации.
Ответ 5
Самый простой способ решить проблему - вручную удалить все элементы, такие как "Schema =" SchemaName "из части модели SSDL.
В этом случае все работает.
Ответ 6
Когда я создаю новую "модель данных сущностей ADO.NET", есть два свойства "Entity Container Name" и "Namespace", доступные для редактирования в представлении дизайна. Используя namespace.EntityContainerName, вы можете создать новый экземпляр указав строку соединения.
MyEntities e = new MyEntities("connstr");
e.MyTable.Count();
Я не уверен, поможет ли это вам или нет, удачи!
Кроме того, это хороший пример для нескольких слоев (не обязательно для проектов, но может быть).
Решение
* DataAccess - Сущности здесь
* Сервис - Обтекает доступ к DataAccess
* Потребитель - Служба звонков
В этом случае потребитель звонит в службу, передавая любой фактор, который определяет, какая строка соединения используется. Затем служба создает экземпляр доступа к данным в соответствующей строке соединения и выполняет запрос пользователя.
Ответ 7
Вот аналогичный вопрос с лучшим ответом:
Изменение имени схемы во время выполнения - Entity Framework
Решение, которое сработало для меня, было тем, что написал Ян Матусек.
Ответ 8
Решил мою проблему, перейдя на сервер sql и от mysql.
Mysql и Mssql интерпретируют "схемы" по-разному. Схемы в mysql одинаковы/синонимы к базам данных. Когда я создал модель, имя схемы, которое совпадает с именем базы данных, жестко закодировано в сгенерированной модели xml. В Mssql схема по умолчанию "dbo", которая получает жесткую кодировку, но это не проблема, поскольку в схемах mssql и в базах данных разные.