Версии доменных имен для утверждения в Grails

Question

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

• Любых изменений на расширенном экземпляре домена, должен быть сохранен (как вариант из него) для истории
• только одна версии экземпляра может быть активный
• Пользователь должен иметь возможность активировать версию экземпляра (текущий активный экземпляр должен быть отключен), который не создал им (4 глаза принцип)
• вид дифф приятно иметь

Вмешательство в Grails из сценариев коробки должно быть как можно меньше. я идентифицировал до сих пор 3 разработки стратегий осуществления:

1. Зеркала таблицы с одной и той же схемой, которая содержит версии (парную графа доменов/таблиц). Активированная версия будет скопирована в собственный домен и наоборот.
2. Использование дискриминатора в классе домена. Некоторые новые колонки будут добавлены в домен (например, состояние [активен, notActive], lastUpdatedBy, lastUpdatedDate ...)
3. (Де-) Сериализация экземпляров в специальной области с BLOB (например, domain.properties в формате JSON)

Любое из решений имеет свои плюсы и минусы. Каков наилучший подход к его внедрению? Возможно, есть более простой способ.

Answer 1

Я разрабатываю систему в Grails, которая интенсивно использует концепцию версии (как вы говорили выше). Мой подход был вторым в вашем вопросе.

Я создал два поля: internalVersion e disabled. Каждый класс, который должен быть Versionable, должен реализовать интерфейс, называемый Versionable.

Я попробую объяснить здесь один из сценариев, в которых необходимо использовать функциональность версии (простите мой английский).

Система, использующая эту концепцию, представляет собой коммерческую систему, в которой есть класс под названием Quote.

Каждая цитата может содержать одну или несколько версий, где действительна только последняя версия. Каждая цитата и ее версии создаются на основе переговоров с конкретным клиентом. Таким образом, клиент запрашивает у нас Цитату, и если по какой-то причине ему не нравятся цены (например), мы можем создать новую версию с некоторой скидкой. Каждая цитата имеет уникальный код, следующий текущей версией, например: QT-000022/0 (первая версия), QT-000022/1 (вторая версия).

Чтобы создать новую версию, я использую метод, который клонирует текущий объект (используя вид полного и глубокого сохранения как). Я копирую все (свойства и коллекции) в новый объект.

Метод клонирования определяет, что класс реализует интерфейс Versionable и выполняет следующие функции:

oldQuote.disabled = true 
newQuote.internalVersion = oldQuote.internalVersion + 1 

Таким образом, это можно гарантировать, что только одна версия будет активирована.

Надеюсь, вы понимаете мой подход.