Definir string como tipo sql de “varchar” em vez de “nvarchar”

Question

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?

Answer 1

Usar .CustomType("AnsiString") em vez de padrão "String" e Nibernate usará varchar ao invés de nvarchar.

Answer 2

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

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

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.