Наилучшая практика для реализации режима долгосрочной истории для системы O / RM (Hibernate)? - PullRequest
4 голосов
/ 15 октября 2008

Я сопоставил несколько java-классов, таких как Customer, Assessment, Rating, ..., с базой данных с помощью Hibernate. Теперь я думаю о режиме истории для всех изменений в постоянных данных. Приложение представляет собой веб-приложение. В случае удаления (или редактирования) данных другой пользователь должен иметь возможность увидеть изменения и отменить их. Поскольку изменения выходят за рамки текущего сеанса, я не знаю, как решить это с помощью шаблона Command, который рекомендуется для отмены функций.

Для редактирования одного значения подход, подобный этому вопрос звучит нормально. Но как насчет удаления целого постоянного объекта? Самый простой способ - создать флаг в таблице, если этот клиент удален или нет. Самый сложный способ - создать таблицу для каждого класса, в которой хранятся удаленные объекты. Есть что-нибудь среднее? И как я могу комфортно интегрировать эти две вещи в систему O / RM (в моем случае Hibernate), не слишком возиться с SQL (чего я хочу избежать из-за переносимости) и при этом иметь достаточную гибкость?

Есть ли лучшая практика?

Ответы [ 3 ]

4 голосов
/ 15 октября 2008

Один из подходов к ведению журнала аудита / отмены - пометить каждую версию записи объекта номером версии. Поиск текущей версии был бы болезненным усилием, если бы это был простой номер версии, поэтому обратная нумерация версий работает лучше всего. «версия» 0 всегда является текущей, и если вы выполняете обновление, номера версий для всех предыдущих версий увеличиваются. Удаление объекта выполняется путем увеличения номеров версий в текущих записях и без добавления новой версии в 0.

По сравнению с подходом «атрибут за атрибутом» это позволяет значительно упростить откат или просмотр исторических версий, но занимает больше места.

2 голосов
/ 15 октября 2008

Один из способов сделать это - создать объект «история изменений» со свойствами измененного идентификатора объекта, действия (редактировать / удалить), имени свойства, оригинального значения, нового значения. Возможно также ссылка на пользователя, выполняющего редактирование. Удаление приведет к созданию сущностей для всех свойств удаленной сущности с действием «удалить».

Эта сущность предоставит достаточно данных для отмены и просмотра истории изменений.

0 голосов
/ 24 ноября 2008

Хм, я тоже ищу ответ на этот вопрос. Пока что лучшее, что я нашел, - это структура www.jboss.org/envers/, но даже мне кажется, что это больше работы, чем необходимо.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...