Hibernate Envers - Поддержка пакетной обработки JDBC в ValidityAuditStrategy с 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(aka RevisionType.MOD и RevisionType.DEL строки).

В настоящее время нет реального обходного пути, чтобы эти операторы могли быть объединены в пакеты, в первую очередь из-за характера того, как эти обновления все равно работают.Стратегия в том виде, в котором она существует, предполагает, что эти предикаты будут влиять на одну строку в таблице, и поэтому также проверяет, что в рамках проверки работоспособности, иначе мы заставим транзакцию завершиться неудачей.

Я думаю, что было бы здоровочтобы найти способ сделать это так, чтобы пакетная вставка / обновления работала, но сначала нам нужно найти способ внедрить эти обновления и поддерживать ту же проверку исправности, где это изменение будет влиять только на одну строку, а не на несколько.что было бы, если бы они были отложены.

Все, что сказал;вся эта логика обрабатывается в ValidityAuditStrategy, который является подключаемым параметром для пользователей, и поэтому вы потенциально можете найти работоспособное решение, которым вы могли бы поделиться с нами.

В любом случае я бы предложил открыть с нами проблему расширения JIRA, и мы можем более подробно обсудить, как (если возможно) наилучшим образом эффективно и более эффективно обрабатывать потенциально поддерживающие пакетные вставки / обновления.