Hibernate Envers - Поддержка пакетной обработки JDBC в ValidityAuditStrategy с allow_identifier_reuse = true

Используя 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 для запросов, чтобы обновить конечную ревизию для любых предыдущих строк?

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
0
646
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Упомянутое вами обновление происходит по нескольким причинам:

  1. Повторное использование идентификатора (что действительно важно только для строк REV_TYPE = 0 или RevisionType.ADD).
  2. REV_TYPE! = 0 (также известные как строки RevisionType.MOD и RevisionType.DEL).

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

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

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

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

Другие вопросы по теме