Impostazione della stringa di essere 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, ha 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 il CustomSqlType, le stringhe sono mappati nvarchar (che fa rispettare la proprietà Length).

Qualche suggerimento?

Answer 1

Usa .CustomType("AnsiString") invece di "String" di default e NHibernate utilizzerà varchar invece di nvarchar.

Answer 2

Se si voleva tutti 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");
    }
}

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 3

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 4

Abbiamo trovato utilizzando il "CustomType (" AnsiString ")" opzione non impedirgli di utilizzare il nvarchar, tuttavia, imposta la lunghezza del campo di 8000 per una colonna che viene specificato come varchar (30). Il 8000 varchar è molto più veloce di 4000 nvarchar, ma è ancora causando enormi problemi con sovraccarico del server SQL.