Реализация истории данных / решение для управления версиями для Того, чтобы быть в спящем режиме - базирующееся приложение (со скручиванием)
Сначала основные факты: веб-приложение Java, Spring, В спящем режиме, MySQL.
Ситуация состоит в том, что у меня есть модель сложного объекта, например, Автомобиль. Это состоит из многих объектов (Механизм, Шины...) с many-one и связями "один ко многим" между ними.
Теперь существует много автомобилей, и время от времени кто-то осматривает автомобиль и создает Сообщение о контроле. Отчет относится ко многим частям что автомобиль, отображая их свойства и т.д.
До сих пор система не поддерживала способность обновить автомобиль и свойства его частей, после того как они питались в систему. Означая, что, если бы цвет шасси или количество шин были изменены, старые отчеты отразили бы это изменение, которое не является тем, что мы хотим.
Ну, теперь эту функцию требовали. Автомобили и их части должны быть модифицируемыми, и история версий должна быть создана. Старые отчеты должны относиться к старым версиям частей и их значений.
Я смотрел "На медленно изменяющиеся размеры", и кажется, что управление версиями автомобиля и его частей могло быть сделано с подходом Типа 6.
Вещь (скручивание), что я испытываю затруднения при выяснении (вероятно, из-за моего ограниченного В спящем режиме опыт) является этим:
Как я могу собраться, мои экземпляры Отчета с В спящем режиме так, чтобы они обратились к правильным версиям каждой части автомобиля? Отчеты имеют дату, и каждая версия автозапчастей имела бы диапазоны даты, когда они были допустимым, таким образом, я предполагаю, что мог сделать это с некоторым сложным HQL/SQL. Но есть ли немного легче, больше автоматического способа сделать, он с В спящем режиме?
3 ответа
Я использовал предложенный вами подход (тип 6) с Hibernate, и он отлично сработал для меня. Запросы к отчетам становились немного сложнее, но не настолько, так как для всех запросов требовалось одно и то же выражение (например, ' и :reportTime >= x.startTime и (:reportTime < x.endTime или x.endTime равен нулю)').
Я создал интерфейс и базовый класс (интерфейс был нужен только для временных подклассов, родитель которых не был временным) для сущностей, которые поддерживали этот подход с 2 свойствами (например, startTime и endTime), и базовый класс для DAO, работающих с временными сущностями, которые часто имели некоторый функционал. Вещи, которые я поместил в этот базовый DAO:
- Предотвращение изменения экземпляров, чей startTime прошел (за исключением установки endTime на будущее время)
- Автоматическое закрытие (т.е. заполнение endTime) предыдущего экземпляра при добавлении нового (например, oldInstance.endTime = newInstance.startTime)
- Добавление стандартного пункта для выбора текущих сущностей при запросе к HQL.
- Работа с дубликатами, если по какой-то причине в момент времени были найдены два правильных экземпляра/версии (я заказывал свои запросы по 'startTime desc' и брал только первый возвращенный)
Единственной частью, где я нашел это действительно неаккуратно, была работа с обычными SQL-запросами, также выполняющимися против БД, где нужны были дополнительные пункты на объединенных таблицах или в подвыборках.
.Вы можете взглянуть на JBoss envers для версионирования ваших объектов. Я не уверен, что он подходит для ваших целей, но посмотрите на него.
.MySQL supports triggers. Установите триггер таким образом, чтобы при каждом изменении строки триггер копировал строку в таблицу "архив" вместе с меткой времени. Таким образом, поддерживаются все предыдущие версии данных, по которым можно запускать отчеты.
.