Ajuste de cadena a tipo SQL de “varchar” en lugar de “nvarchar”
-
23-09-2019 - |
Pregunta
Tengo el siguiente mapeo:
public class LogEntryMap
{
public LogEntryMap()
{
Map.Id(x => x.Id).GeneratedBy.Identity();
Map(x => x.Context).CustomSqlType("varchar").Length(512);
}
}
ignora Sin embargo, utilizando SchemaExport
para generar la base de datos en SQL Server 2008, el script generado la longitud lo que en efecto que termina siendo un varchar
con longitud de 1:
create table OV_SAC.dbo.[LogEntry] (
Id BIGINT IDENTITY NOT NULL,
Context varchar null,
primary key (Id)
)
.CustomSqlType("varchar 512")
lanza una excepción. Y sin definir el CustomSqlType
, las cadenas se asignan a nvarchar
(que hace respetar la propiedad Length
).
¿Alguna sugerencia?
Solución
Uso .CustomType("AnsiString")
en lugar de "String"
defecto y NHibernate utilizará varchar
en lugar de nvarchar
.
Otros consejos
Si quieres todos de sus cadenas que se asignan a varchar en lugar de nvarchar se podría considerar el uso de una convención:
/// <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");
}
}
asignaciones podría entonces volver a una asignación simple:
Map(x => x.Context);
Sólo asegúrese de recordar para contar Fluido NH utilizar la convención:
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)
)
Nos encontramos con el "CustomType (" AnsiString ")" opción de evitar que se hace uso de la nvarchar, sin embargo, se establece la longitud del campo de 8000 para una columna que se especifica como varchar (30). El varchar 8000 es mucho más rápido que nvarchar 4000, pero todavía está causando enormes problemas con la sobrecarga del servidor SQL.