Установка строки типа sql «varchar» вместо «nvarchar»
-
23-09-2019 - |
Вопрос
У меня есть следующее отображение:
public class LogEntryMap
{
public LogEntryMap()
{
Map.Id(x => x.Id).GeneratedBy.Identity();
Map(x => x.Context).CustomSqlType("varchar").Length(512);
}
}
Однако, используя SchemaExport
для создания базы данных в SQL Server 2008 созданный сценарий игнорирует длину, поэтому фактически он оказывается 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
свойство).
Какие-либо предложения?
Решение
Использовать .CustomType("AnsiString")
вместо дефолта "String"
и NHibernate будет использовать varchar
вместо nvarchar
.
Другие советы
Если бы ты хотел все ваших строк, которые будут отображаться в 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();
Дох.
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)
)
Мы обнаружили, что использование параметра «CustomType(»AnsiString»)» не позволяет использовать nvarchar, однако он устанавливает длину поля 8000 для столбца, указанного как varchar(30).8000 varchar намного быстрее, чем 4000 nvarchar, но он по-прежнему вызывает огромные проблемы с накладными расходами сервера sql.