Definir string como tipo sql de “varchar” em vez de “nvarchar”
-
23-09-2019 - |
Pergunta
Tenho o seguinte mapeamento:
public class LogEntryMap
{
public LogEntryMap()
{
Map.Id(x => x.Id).GeneratedBy.Identity();
Map(x => x.Context).CustomSqlType("varchar").Length(512);
}
}
No entanto, usando SchemaExport
para gerar o banco de dados no SQL Server 2008, o script gerado ignora o comprimento e na verdade acaba sendo um varchar
com comprimento de 1:
create table OV_SAC.dbo.[LogEntry] (
Id BIGINT IDENTITY NOT NULL,
Context varchar null,
primary key (Id)
)
.CustomSqlType("varchar 512")
lança uma exceção.E sem definir o CustomSqlType
, as strings são mapeadas para nvarchar
(que respeita o Length
propriedade).
Alguma sugestão?
Solução
Usar .CustomType("AnsiString")
em vez de padrão "String"
e Nibernate usará varchar
ao invés de nvarchar
.
Outras dicas
Se você quisesse tudo de suas cordas a serem mapeadas para Varchar, em vez de Nvarchar, você pode considerar usar uma convenção:
/// <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");
}
}
Vocês mapeamentos podem voltar a um mapeamento simples:
Map(x => x.Context);
Apenas lembre -se de dizer ao Fluent NH para usar a convenção:
var configuration = new Configuration();
configuration.Configure();
Fluently
.Configure(configuration)
.Mappings(m => m.FluentMappings
.AddFromAssemblyOf<Widget>()
.Conventions.Add<OurStringPropertyConvention>()
)
.BuildSessionFactory();
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)
)
Descobrimos que o uso da opção "CustomType("AnsiString")" impede o uso do nvarchar, no entanto, ela define o comprimento do campo de 8000 para uma coluna especificada como varchar(30).O varchar 8000 é muito mais rápido que o nvarchar 4000, mas ainda causa enormes problemas com a sobrecarga do servidor SQL.