java - Hibernate Envers - 在 ValidityAuditStrategy 中支持 JDBC 批处理(allow_identifier_reuse=true)

Question

使用 Hibernate + Envers(版本 5.2.17.Final)，我尝试保留大约 250000 个 JPA 实体，并使用 Envers ValidityAuditStrategy 审核初始插入。我正在使用 JDBC 批处理来提高性能。我看到两者都发生了批处理

• 插入基表(即 INSERT INTO dbo.EXAMPLE_TABLE)
• 插入审核表(即 INSERT INTO dbo.EXAMPLE_TABLE_AUD)

但不适用于用于更新任何先前审核行的最终修订的查询，我相信在设置 allow_identifier_reuse=true 时启用了该查询(这对于我的用例是强制性的)。这些更新查询之一的示例:

update
    dbo.example_table_aud
set
    revend=? 
where
    id=? 
    and rev<> ? 
    and revend is null

实体代码:

@Entity
@Audited
@Table(schema = "dbo", name = "EXAMPLE_TABLE")
public class ExampleEntity {

    @Id
    @Column(name = "ID", nullable = false)
    private long id;

    @Column(name = "NAME", nullable = false)
    private String name;

    @Version
    @Column(name = "VERSION", nullable = false)
    private int version;

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getVersion() {
        return version;
    }

    public void setVersion(int version) {
        this.version = version;
    }
}

Hibernate/Envers 配置:

  org.hibernate.envers:
    audit_table_suffix: _AUD
    revision_field_name: REV
    revision_type_field_name: REVTYPE
    default_schema: dbo
    audit_strategy: org.hibernate.envers.strategy.ValidityAuditStrategy
    do_not_audit_optimistic_locking_field: false
    store_data_at_delete: true
    allow_identifier_reuse: true
  hibernate:
    dialect: org.hibernate.dialect.SQLServer2012Dialect
    format_sql: true
    jdbc.batch_size: 100
    jdbc.batch_versioned_data: true
    order_inserts: true
    order_updates: true

是否有解决方法可以使用 JDBC 批处理进行查询来更新任何先前行的最终修订？

Answer 1

您提到的更新发生有几个原因:

1. 标识符重用(实际上仅对 REV_TYPE = 0 或 RevisionType.ADD 行很重要)。
2. REV_TYPE != 0(又名 RevisionType.MOD 和 RevisionType.DEL 行)。

目前没有真正的解决方法可以对这些语句进行批处理，这主要是因为这些更新的工作方式的本质。现有的策略期望这些谓词影响表中的单行，因此也会将其作为健全性检查的一部分进行检查，否则我们会强制事务失败。

我认为找到一种方法来执行此操作以便批量插入/更新可以工作是很棒的，但我们首先必须找到一种方法来实现这些更新并维护相同的健全性检查，其中只有一行会受到该变化的影响，而不是受到延迟的多重影响。

说了这么多；所有这些逻辑都在 ValidityAuditStrategy 内处理，这是用户的可插入选项，因此您可能会找到一个可以与我们分享的可行解决方案。

无论哪种情况，我都建议向我们提出 JIRA 增强问题，我们可以更详细地讨论如何(如果可能)最好地有效且更高效地处理潜在的支持批量插入/更新。