Обработка кастомных типов с уведомлением об успешности транзакции

[bratchikov]

Цель

Кастомные типы, которые используют те или иные ресурсы нуждаются в получении информации о результате записи в БД: успешно или нет.

Функциональные требования

Требуется разработать интерфейс для кастомных типов в дополнение к интерфейсу из #59 для поддержки вызова методов, фиксирующих результат выполнения операции в БД.

Требования к реализации

Нужно несколько методов:

• Метод, который вызовется непосредственно перед выполнением транзакции (все БСы уже сработали)
• Метод, который вызовется в случае успешного завершения транзакции
• Метод, который вызовется в случае неуспешного завершения транзакции

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

При реализации придётся использовать специальные массивы или словари для того, чтобы увязать результат выполнения транзакции с объектом данных. Это нужно для того, чтобы можно было передать объект данных в метод.

Исходный код

Этот репозиторий, сделать feature-ветку от develop.

Документация

Добавить статью в документацию (issue без статьи не закрывать)

Тесты

Реализовать тесты.

Примерная оценка трудоёмкости

16ч.

[mao29]

Помимо информации об объекте данных нужно еще видимо получать имя поля, для которого срабатывает метод.

[mao29]

Из такой постановки мало понятно с какого места и в какую сторону начинать копать. Предлагаю добавить ссылки на конкретные файлы ОРМ, где требуется добавить эту функциональность.

[mao29]

Абзац про специальные массивы и словари не понял.

[mao29]

А почему предлагается дополнительный интерфейс сделать, а не дополнить тот, что в рамках #59 предполагается разработать? Есть сценарий как их по-отдельности использовать? Или просто во имя SRP?

[NicholasNoise]

В текущей реализации сервиса данных это всё очень похоже на принцип взаимодействия с сервисом аудита:
перед выполнением query-запросов (link)
после всех query-запросов (link)
в случае исключения выполнения любого query-запроса (link)

[NicholasNoise]

Данный интерфейс может быть реализован как кастомным типом (например, GeoData), так и наследником от DataObject?
Первое может быть использовано для реализации логики сохранения сложных типов, объекты которых хранятся распределённо - метаданные в БД, а контент - в ином месте, который можно получить по метаданным.
Второе - для реализации логики оповещения об изменении объекта данных.

Между этими вариантами есть отличие в контексте методов из интерфейса:
1 - тройка (DataObject,PropertyName,PropertyValue)
2 - только (DataObject), т.к. PropertyName = null, а PropertyValue совпадает с DataObject.

[NicholasNoise]

Под специальными массивами, вероятно, Игорем подразумевалась некая коллекция всех экземпляров классов, которые реализуют создаваемый интерфейс. Такую коллекцию необходимо будет сформировать перед или во время выполнения Метод0, чтобы позднее переиспользовать в Метод1 или Метод2.