stringa di impostazione per essere di tipo SQL di "varchar" invece di "nvarchar"

Question

Ho il seguente mappatura:

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

Tuttavia, utilizzando SchemaExport per generare il database in SQL Server 2008, generato lo script ignora la lunghezza così in effetti si finisce per essere un varchar con lunghezza di 1:

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

.CustomSqlType("varchar 512") genera un'eccezione. E senza definire lo CustomSqlType, le stringhe sono mappate su nvarchar (che rispetta la proprietà Length).

Qualche suggerimento?

Answer 1

Uso .CustomType("AnsiString") al posto di predefinito "String" e NHibernate utilizzerà varchar invece di nvarchar.

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

se si voleva tutte delle corde da mappare a VARCHAR invece di nvarchar si potrebbe considerare l'utilizzo di una convenzione:

/// <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"); 
    } 
} 

Voi mappature potrebbe quindi tornare a una semplice mappatura:

Map(x => x.Context); 

Basta assicurarsi che si ricorda di dire Fluent NH a utilizzare la convenzione:

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

Answer 4

Abbiamo trovato che l'utilizzo dell'opzione "CustomType (" AnsiString ")" impedisce l'utilizzo di nvarchar, tuttavia imposta la lunghezza del campo di 8000 per una colonna specificata come varchar (30). L'8000 varchar è molto più veloce di 4000 nvarchar, ma continua a causare enormi problemi con l'overhead del server SQL.