2016-09-15 3 views
0

Я использую NHibernate с отображением по коду, связанным с SQL Server. Этот сервер также содержит таблицы файлов.NHibernate hierarchyid SQL Server 2014

Клиент, для которого я разрабатываю, имеет SQL Server 2012, который я также имел довольно долгое время. Из-за недавней ошибки в VM, на которой работает мой локальный сервер, я в настоящее время пытаюсь запустить свой код с базы данных на localhost, который является SQL Server 2014.

Я получил резервную копию из базы данных клиентов и восстановил ее мой локальный сервер.

Прежде чем все прошло хорошо, мой код работал без особых проблем. Но когда я теперь пытаюсь подключиться к моей локальной БД, NHibernate генерирует исключение:

Неверный тип столбца в sql_pig_pool.dbo.tbl_Abgabebeleg_Dateien для столбца path_locator. Найдено: hierarchyid, Ожидаемый NVARCHAR (255)

Когда я меняю строку подключения на клиентскую БД, все работает снова. Я предполагаю, что что-то изменилось в SQL Server 2012-> 2014, или какая-то локальная конфигурация на моей рабочей станции неверна.

UPDATE: Теперь я установил SQL Server 2012 локально и восстановил свою базу данных там. Та же ошибка, что и в 2014 году. Таким образом, разница должна быть связана с некоторой локальной конфигурацией.

Мой класс:

public class TblAbgabebelegDateien 
{ 
    public TblAbgabebelegDateien() { stream_id = Guid.NewGuid(); } 
    public virtual string path_locator { get; set; } 
    public virtual TblAbgabebelegDateien tbl_AbgabebelegDateienVal { get; set; } 
    public virtual Guid stream_id { get; set; } 
    public virtual byte[] file_stream { get; set; } 
    public virtual string name { get; set; } 
    public virtual string file_type { get; set; } 
    public virtual long? cached_file_size { get; set; } 
    public virtual string creation_time { get; set; } 
    public virtual string last_write_time { get; set; } 
    public virtual string last_access_time { get; set; } 
    public virtual bool is_directory { get; set; } 
    public virtual bool is_offline { get; set; } 
    public virtual bool is_hidden { get; set; } 
    public virtual bool is_readonly { get; set; } 
    public virtual bool is_archive { get; set; } 
    public virtual bool is_system { get; set; } 
    public virtual bool is_temporary { get; set; } 
} 

Мое отображение:

public class TblAbgabebelegDateienMap : ClassMapping<TblAbgabebelegDateien> { 

    public TblAbgabebelegDateienMap() { 
     Schema("dbo"); 
     Table("tbl_Abgabebeleg_Dateien"); 
     Lazy(true); 
     Id(x => x.path_locator, map => map.Generator(Generators.Assigned)); 
     Property(x => x.stream_id, map => { map.NotNullable(true); map.Unique(true); }); 
     Property(x => x.file_stream); 
     Property(x => x.name, map => 
     { 
      map.NotNullable(true); 
      map.Unique(true); 
      map.Length(255); 
     }); 
     Property(x => x.file_type, map => map.Length(255)); 
     Property(x => x.cached_file_size, map => map.Precision(19)); 
     Property(x => x.creation_time, map => map.NotNullable(true)); 
     Property(x => x.last_write_time, map => map.NotNullable(true)); 
     Property(x => x.last_access_time); 
     Property(x => x.is_directory, map => map.NotNullable(true)); 
     Property(x => x.is_offline, map => map.NotNullable(true)); 
     Property(x => x.is_hidden, map => map.NotNullable(true)); 
     Property(x => x.is_readonly, map => map.NotNullable(true)); 
     Property(x => x.is_archive, map => map.NotNullable(true)); 
     Property(x => x.is_system, map => map.NotNullable(true)); 
     Property(x => x.is_temporary, map => map.NotNullable(true)); 
     ManyToOne(x => x.tbl_AbgabebelegDateienVal, map => 
     { 
      map.Column("parent_path_locator"); 
      map.PropertyRef("path_locator"); 
      map.Cascade(Cascade.None); 
     }); 
    } 
} 

Кто-нибудь есть идея, что я должен изменить, так что я могу использовать эти таблицы снова? Мне даже не нужен локатор пути (я обращаюсь к файлам через stream_id), но это ПК, так что это важно. NHibernate не любит отсутствующее свойство Id в его сопоставлении.

Я только прочитал эти таблицы, поэтому любая конфигурация, которая позволяет мне получить доступ к таблице файлов, приветствуется.

Я видел проект GitHub (NHibernate.HierarchyId), но он предназначен для плавного отображения, а не для отображения по коду. Я не могу просто использовать строку «hierarchyid» в моем сопоставлении для типа. Мои личные попытки создания класса, основанного на IUserType, также потерпели неудачу.

Дополнение: У меня нет подпапки «Индексы» в SQL Server Management Studio больше на моей локальной БД. Он по-прежнему доступен в моей базе данных клиентов (с 3 индексами: PK на path_locator, UQ на stream_id, UQ на parent_path_locator + name). Является ли это релевантным в любом виде? UPDATE В моем новом экземпляре 2012 года я снова имею эту папку индексов.

+0

Это ошибка NHibernate, в которой говорится, что NHibernate не знает, что делать с 'hierarchyId'. NHibernate не поддерживает 'hierarchyId' без добавления типа [NHibernate.HierarchyId] (https://www.nuget.org/packages/NHibernate.HierarchyId/). Свободное сопоставление * - это отображение по коду - методы «свободного» вызова вызывают точный код, который вы делаете. Пакет NuGet добавляет поддержку «hierarchyId» в первую очередь. Он не содержит кода, специфичного для Fluent. На самом деле, образцы просто используют строку '' hierarhcyId '', где требуется имя типа в сопоставлениях –

+0

Но что же отличается в версии иерархии SQL Server 2014 по сравнению с SQL Server 2012? В 2012 году он отобразился в строку без необходимости в дополнительном пакете. – MilConDoin

+0

@PanagiotisKanavos Я не могу найти класс, который наследуется от IUserType, который мне нужен для сопоставления кодом, если я правильно понял механику. 'Id (x => x.path_locator, map => {map.Generator (Generators.Assigned); map.Type ();});' – MilConDoin

ответ

0

Все сводилось к одному из важнейших разницы:

В моей конфигурации IDbIntegrationConfigurationProperties, у меня не было db.SchemaAction, определенный для моей оригинальной версии, но db.SchemaAction = SchemaAutoAction.Validate для моей текущей версии.

Простое удаление проверки снова привело к полностью работающему решению.

Рабочие часы, потраченные впустую для этой немой ошибки.

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