cadena de Ajuste que debe tipo SQL de "varchar" en lugar de "nvarchar"

Question

Tengo el siguiente mapeo:

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

Sin embargo, el uso de SchemaExport para generar la base de datos en SQL Server 2008, generó la secuencia de comandos hace caso omiso de 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") produce una excepción. Y sin definir el CustomSqlType, las cadenas se asignan a nvarchar (que respeta la propiedad Length).

¿Alguna sugerencia?

Answer 1

Uso .CustomType("AnsiString") en lugar de por defecto "String" y NHibernate utilizará en lugar de varcharnvarchar.

Answer 2

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) 
) 

Answer 3

Si querían todo de sus cadenas a ser mapeadas a varchar en lugar de nvarchar usted 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"); 
    } 
} 

You asignaciones podría entonces volver a una asignación simple:

Map(x => x.Context); 

Sólo asegúrese de que recuerde que 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(); 

Answer 4

Encontramos que usar la opción "CustomType (" AnsiString ")" impide que use el nvarchar, sin embargo, 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 4000 nvarchar, pero todavía está causando grandes problemas con la sobrecarga del servidor sql.