CRUD.save () с отметкой времени из БД

Учитывая ваш список требований, у вас реально есть 3 варианта

1. Используйте триггер базы данных в своей таблице для управления значениями метки времени обновления.
2. Используйте обратный вызов @PreUpdate.
3. Сделайте это как часть вашей службы, когда у вас есть доступ к состоянию обновления и существующему состоянию.

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

Единственным недостатком между (1) и (2) является то, что (2) нет будет основываться на времени базы данных, а скорее на времени приложения, потому что вы будете делать это на сервере приложений. Но (2) имеет то преимущество, что ваш код для этого будет независимым от базы данных, что позволит вам развернуть его где угодно на любой платформе базы данных, которую поддерживает Hibernate или имеет функционирующий диалект, без каких-либо проблем.

Мое личное мнение, выберите (2), потому что он также довольно сфокусирован на предметно-ориентированном дизайне.

Для реализации (2) это довольно просто.

@Entity
public class YourSuperDumperEntity {

  // Clear this value on load
  @PostLoad
  public void postLoadClearFlags() {
    fieldValuesChangedThatRequireTimestampUpdate = false;
  }

  // This handles the setting of the value at update-time
  @PreUpdate
  public void preUpdateCallbackAdjustTimestampOnChanges() {
    if ( fieldValuesChangedThatRequireTimestampUpdate ) {
      updateTimestamp = new Date();
    }
  }


  public void setSomeFieldThatTriggersUpdateTimestamp(String value) {
    // check if the old and new value differ enough to trigger update date
    // if so, set the boolean flag here as follows
    this.fieldValuesChangedThatRequireTimestampUpdate = true;

    // now set the value
    this.someFieldThatTriggersUpdateTimestamp = value;
  }
}

Как я указывал ранее, прелесть здесь заключается в том, что вся логика этого самодостаточна в одном классе, которому она принадлежит, потому что то, о чем вы говорите, - это состояние сущности.

Возможно, вам придется немного поиграть с обратными вызовами JPA, чтобы удовлетворить ваши потребности, но идея остается той же.

Если вам не нравится (2), тогда я предлагаю (3), потому что он поддерживает независимую от базы данных поддержку, что я считаю гораздо более важным, чем временная метка, полученная из самой базы данных. При правильной синхронизации времени операционной системы фактический источник времени не имеет значения.

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