chaîne de type paramètre à sql de « varchar » au lieu de « nvarchar »

Question

Je le mapping suivant:

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

Cependant, l'utilisation SchemaExport pour générer la base de données dans SQL Server 2008, le script généré ne tient pas compte de la longueur donc en effet, il finit par être un varchar avec une longueur de 1:

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

.CustomSqlType("varchar 512") lève une exception. Et sans définir le CustomSqlType, les chaînes sont mises en correspondance avec nvarchar (qui ne respecte la propriété Length).

Toutes les suggestions?

Answer 1

Utilisation .CustomType("AnsiString") au lieu de "String" par défaut et NHibernate utilisera varchar au lieu de nvarchar.

Answer 2

Si vous voulez tous de vos chaînes à être mises en correspondance varchar au lieu de nvarchar vous pourriez envisager d'utiliser une convention:

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

Vous pouvez ensuite mappings revenir à une cartographie simple:

Map(x => x.Context);

Assurez-vous que vous vous souvenez de dire NH Courant d'utiliser la convention:

        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

Nous avons trouvé en utilisant le « CustomType ( » AnsiString « ) » option ne l'empêcher d'utiliser le nvarchar, cependant, il définit la longueur du champ de 8000 pour une colonne qui est spécifié comme varchar (30). Le 8000 varchar est beaucoup plus rapide que 4000 nvarchar, mais il est à l'origine encore d'énormes problèmes avec les frais généraux du serveur SQL.