Как изменить столбец, используя функциональность nhibernate SchemaUpdate

#c# #.net #nhibernate #c#-4.0 #fluent-nhibernate

#c# #.net #nhibernate #c #-4.0 #свободно-nhibernate

Вопрос:

У меня есть модель сущности, которую я хочу отражать в базе данных при каждом запуске приложения, но без очистки данных, поэтому я использую SchemaUdpate метод fluent nhibernate mappings в некотором роде

 var config = Fluently.Configure().Database
(MsSqlConfiguration.MsSql2008.ConnectionString(connectionString));
//here I add mappings , apply conventions, build configuration, etc...
//
new SchemaUpdate(configuBuild).Execute(doUpdate: true, script: true);
 

Таким образом, моя модель сущности обновляется корректно почти все время. Проблема в том, что когда я изменяю определение свойства, допустим, у меня было такое свойство

  [CustomSqlType("nvarchar(400)")]
 public virtual string Name { get; set; }
 

CustomSqlType это просто атрибут, который будет применяться по определенному соглашению при загрузке сопоставлений. В этом случае свойство Name будет создано как nvarchar(400) поле. Но если в будущем я изменю определение на это

  [CustomSqlType("nvarchar(500)")]
 public virtual string Name { get; set; }
 

чем правильно hbm.xml файл будет сгенерирован (правильно означает nvarchar(500)), но столбец в базе данных не обновляется, хотя такое изменение допустимо с точки зрения базы данных.
Можно ли изменить (сгенерировать сценарий изменения) существующий столбец с использованием нового ограничения длины / точности / nullable SchemaUpdate ?

Ответ №1:

Хорошо, я обнаружил, что это невозможно, ниже приведен код, выполняемый SchemaUpdate

 foreach (Column column in ColumnIterator)
        {
            IColumnMetadata columnInfo = tableInfo.GetColumnMetadata(column.Name);
            if (columnInfo != null)
            {
                continue;
            }

            // the column doesnt exist at all.
            // other not important code
        }
 

Как вы видите, по умолчанию он ничего не делает, если столбец существует.

Комментарии:

1. Это действительно воняет. Что вы в конечном итоге сделали, чтобы принудительно обновить вашу схему?

2. Спасибо! Я потратил годы, пытаясь выяснить, почему, похоже, он не обновляет мои ограничения по умолчанию! — Удалось ли вам найти обходной путь?