Установка строки для типа sql "varchar" вместо "nvarchar"

У меня есть следующее отображение:

public class LogEntryMap
{
    public LogEntryMap()
    {
        Map.Id(x => x.Id).GeneratedBy.Identity();
        Map(x => x.Context).CustomSqlType("varchar").Length(512);
    }
}

Однако, используя SchemaExport для создания базы данных в SQL Server 2008, созданный script игнорирует длину, поэтому она заканчивается как varchar с длиной 1:

create table OV_SAC.dbo.[LogEntry] (
    Id BIGINT IDENTITY NOT NULL,
   Context varchar null,
   primary key (Id)
)

.CustomSqlType("varchar 512") выдает исключение. И без определения CustomSqlType строки отображаются на nvarchar (что уважает свойство Length).

Любые предложения?

Ответ 1

Используйте .CustomType("AnsiString") вместо значения по умолчанию "String", а NHibernate будет использовать varchar вместо nvarchar.

Ответ 2

Если вы хотите, чтобы все ваших строк отображались в varchar вместо nvarchar, вы могли бы рассмотреть использование соглашения:

/// <summary>
/// Ensures that all of our strings are stored as varchar instead of nvarchar.
/// </summary>
public class OurStringPropertyConvention : IPropertyConvention
{
    public void Apply(IPropertyInstance instance)
    {
        if (instance.Property.PropertyType == typeof (string))
            instance.CustomType("AnsiString");
    }
}

Затем вы можете вернуться к простому сопоставлению:

Map(x => x.Context);

Просто убедитесь, что вы не забыли сообщить Fluent NH об использовании соглашения:

        var configuration = new Configuration();
        configuration.Configure();
        Fluently
            .Configure(configuration)
            .Mappings(m => m.FluentMappings
                .AddFromAssemblyOf<Widget>()
                .Conventions.Add<OurStringPropertyConvention>()
                )
            .BuildSessionFactory();

Ответ 3

Doh.

Map(x => x.Context).CustomSqlType("varchar (512)");

create table OV_SAC.dbo.[LogEntry] (
    Id BIGINT IDENTITY NOT NULL,
   Context varchar (512) null,
   primary key (Id)
)

Ответ 4

Мы обнаружили, что использование опции "CustomType (" AnsiString ") не позволяет использовать nvarchar, однако она устанавливает длину поля 8000 для столбца, который указан как varchar (30). 8000 varchar намного быстрее, чем 4000 nvarchar, но он по-прежнему вызывает огромные проблемы с накладными расходами sql-сервера.