Блог

Главная - Вопросы по программированию - Рефакторинг пакета событий Axon Framework

Рефакторинг пакета событий Axon Framework

#axon #axon-framework

Вопрос:

У меня есть набор событий, которые были перенесены в другой пакет. Это работает как есть, пока я не выполню повтор события. Копая глубже, я заметил тип payload в таблице domainevententry и решил, что этого будет достаточно, но, увы, похоже, что корневой элемент xml события также необходимо изменить. Я надеюсь, что есть простой способ сделать это.

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

Спасибо

Ответ №1:

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

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

При использовании (по умолчанию) XStreamSerializer псевдонимы тегов действительно также будут работать. Как установить псевдонимы, можно увидеть, например, здесь. КАК отмечено в этом примере, псевдоним добавляется к XStream экземпляру. Экземпляр XStreamSerializer используется XStream для поддержки де-/сериализации из/в XML. Чтобы настроить XStream экземпляр, вы можете просто использовать парадигму конструктора на XStreamSerializer . JavaDoc конструктора должен быть достаточно конкретным, чтобы помочь вам понять, как его использовать.

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

1. Спасибо, Стивен, как всегда, несколько настоящих жемчужин в твоем ответе. Не знаю, как я пропустил EventTypeUpcaster! Определенно буду делать это таким образом в будущем.

2. Приятно слышать, что это может помочь вам в дальнейшем, Кеннет!

Ответ №2:

Проделал долгий путь с этим, но, похоже, это работает. Как всегда, сделайте резервную копию своей базы данных перед выполнением изменений большого объема. Я также перезапустил службу, используя базу данных по завершении. Излишне говорить, что я удостоверюсь, что события находятся в логических пакетах перед развертыванием в следующий раз 🙂

Ядро базы данных: Postgres 10

Таблица: domainevententry

     update domainevententry
    set
        payloadtype = '<new.package.Classname>',
        payload = lo_from_bytea(0, decode(REPLACE(
            subquery.output,
            '<old.package.Classname>',
            '<new.package.Classname>'
            ), 'escape'))
    from (
        SELECT eventidentifier, payloadtype, encode(lo_get(payload::oid), 'escape') as output FROM domainevententry
        WHERE eventidentifier in (
            '<event guid 1>',
            '<event guid 2>'
        )
        AND payloadtype = '<old.package.Classname>'
    ) as subquery
    where domainevententry.eventidentifier = subquery.eventidentifier;

Как только это будет завершено, мне нужно будет обновить ВЛАДЕЛЬЦА большого объекта:

 ALTER LARGE OBJECT <LargeObjectId> OWNER TO database_role;

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

Запуск повторов каркаса Аксона восстановил проекции, и все выстроилось в ряд.

Метки: