Как стать автором
Обновить

Комментарии 11

Всё это выглядит очень здорово и красиво, но как быть, если объём данных большой или данные часто изменяются? Если работа с БД ведётся не только через Hibernate? Не говоря уже о том, что кто-то может влезть и руками поправить данные. Имхо, надёжнее будет сделать через триггеры, хотя переносимость при этом и пострадает.
С первой частью утверждения согласен. Да и вообще настройка этого envers выглядит как колдовство. Но триггеры не лучшая альтернатива. Я бы сделал все на message queue. Произошло событие — кинул соответствующее сообщение.
Лучше всего использовать для ловли событий аспекты, а дальше что в коде напишете то и будет.
На мой взгляд аспекты еще большее колдовство, усложняется как логика, так и отладка приложения.
Как раз нет. Надо просто один раз понять как они работают. Их для кроссфункциональности (логгирование, аудит и прочее) применять существенно удобнее
Можно и аспекты использовать, наверное. Правда я не очень представляю как :) Вот к примеру:

private EventBus eventBus;

public void doSomething() {

Order order = createOrder();
eventBus.raiseEvent(Events.orderCreated(order));

}

Где EventBus интерфейс.

С аспектами как-то сложнее. Наверное придется завязаться на возвращаемое значение метода. Как-то так:

@Raise(OrderCreated.class)
public Order createOrder() {
}
Используйте аспекты. Они позволяют делать не только аудит, а все что угодно :)
Во многих промышленных СУБД механизмы трекинга и аудита уже встроены.

А вообще я не нашел упоминаний можно ли писать аудит в другую базу (ее ведь проще обслуживать будет, да и скорость основной базы не будет так сильно страдать)…
Интересно. А что будет добавляться в аудит, если запись убирается?
В таблицу аудита добавляется запись с последним состоянием сущности и revtype равным DEL(2 вроде).
Всё так, только насколько я помню, запись получается не с последним состоянием сущности (оно есть в предыдущей записи), а с пустыми полями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории