将字符串设置为“varchar”的sql类型而不是“nvarchar”

发布于 2024-08-23 07:04:14 字数 655 浏览 11 评论 0原文

我有以下映射:

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

但是,使用 SchemaExport 在 SQL Server 2008 中生成数据库,生成的脚本会忽略长度,因此实际上它最终成为具有长度的 varchar 1:

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

.CustomSqlType("varchar 512") 引发异常。如果不定义 CustomSqlType,字符串就会映射到 nvarchar(它确实尊重 Length 属性)。

有什么建议吗?

I have the following mapping:

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

However, using SchemaExport to generate the database in SQL Server 2008, the script generated ignores the length so in effect it ends up being a varchar with length of 1:

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

.CustomSqlType("varchar 512") throws an exception. And without defining the CustomSqlType, strings are mapped to nvarchar (which does respect the Length property).

Any suggestions?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

樱&纷飞 2024-08-30 07:04:14

使用 .CustomType("AnsiString") 而不是默认的 "String",NHibernate 将使用 varchar 而不是 nvarchar

Use .CustomType("AnsiString") instead of default "String" and NHibernate will use varchar instead of nvarchar.

泪之魂 2024-08-30 07:04:14

如果您希望将所有字符串映射到 varchar 而不是 nvarchar,您可以考虑使用约定:

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

然后您的映射可以返回到简单的映射:

Map(x => x.Context);

只需确保你记得告诉 Fluent NH 使用约定:

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

If you wanted all of your strings to be mapped to varchar instead of nvarchar you could consider using a 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");
    }
}

You mappings could then go back to a simple mapping:

Map(x => x.Context);

Just make sure you remember to tell Fluent NH to use the convention:

        var configuration = new Configuration();
        configuration.Configure();
        Fluently
            .Configure(configuration)
            .Mappings(m => m.FluentMappings
                .AddFromAssemblyOf<Widget>()
                .Conventions.Add<OurStringPropertyConvention>()
                )
            .BuildSessionFactory();
旧梦荧光笔 2024-08-30 07:04:14

哦。

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

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)
)
所谓喜欢 2024-08-30 07:04:14

我们发现使用“CustomType("AnsiString")”选项确实会阻止它使用 nvarchar,但是,它会将指定为 varchar(30) 的列的字段长度设置为 8000。 8000 varchar 比 4000 nvarchar 快得多,但它仍然会导致 sql server 开销的巨大问题。

We found using the "CustomType("AnsiString")" option does prevent it from using the nvarchar, however, it sets the field length of 8000 for a column that is specified as varchar(30). The 8000 varchar is much faster than 4000 nvarchar, but it is still causing huge problems with sql server overhead.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文