Васе повысили ЗП на 1.5к, из них 500 это премия, а 1к оклад, и нам нужно все данные, которые до этого были разделить на премию и оклад

Так же!

А как изменить уже внесённые данные?

или ЗП разделили на две части - чорный нал и белая ) и повышать могут любую. А раньше это была тупо сумма

А как изменить уже внесённые данные?

А зачем?

Это плохой пример потому что такого не будет

Поясню

А зачем?

Ну требование такое

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

Существующие евенты никогда не меняются

Ну требование такое

Плохое требование

Они же евенты. Они уже случились

Раньше мы везде показывали общую ЗП, но при разработке нового сервиса, оказалось, что нам важно сейчас разделять ЗП на оклад и премию

И нам нужно все данные поменять, чтобы теперь хранить ЗП и премию отдельно

Раньше мы везде показывали общую ЗП, но при разработке нового сервиса, оказалось, что нам важно сейчас разделять ЗП на оклад и премию

Раньше премий не было? Как разделялись при разработке

Это правда нереальный пример.

Раньше премий не было? Как разделялись при разработке

Было, но нужна была общая ЗП, а премия и оклад не важны

Было, но нужна была общая ЗП, а премия и оклад не важны

Такого не бывает, у тебя ж во всём домене тогда не будет разделений. Или где-то логика по разделению за на премию и оклад была. Или она вновь появилась тогда просто читай старые стримы и агрегируй

вопрос как старые ивенты накатить на новый стейт?

Ну смотри реальный пример

вопрос как старые ивенты накатить на новый стейт?

Кодом) ну серьезно, ничем не отличается

Вот у нас была деталь, и было поле со стандартом изготовления детали ГОСТ 1234 ТУ 1234 ОСТ 1234 Раньше всё писали в базе в одно поле, потом выяснилось, что нужно разделение, отдельно тип стандарта и его код, соответственно разделили на две ячейки ГОСТ | 1234 ТУ | 1234 ОСТ | 1234 Чтобы пофиксить существующие данные, мы просто руками прошлись и разнесли их, как быть со стейтом в данном случае?

Ответ тот же) Берешь евент стрим и фолдишь в модель с раздельными полями. Код для разбивания строки по пробелам показывать?)

Там не всё так просто, нужно именно руками было разбивать

Так как все пишут по разному

И там 60 разных вариаций

Где-то есть косячные данные

ГОСТ1234

Всего 60

Даже были варианты с английскими буквами OCT

Ну сделаешь кастомный мапинг, зашиваешь в код

Или отправляй из сервиса письмо или евент если не может прочитать строчку

Так а дальше так же и продолжать передавать одной строкой?

И фолдить?

И тут появляется снапшот!

Один раз зафолдил, сохранил чекпоинт и все

А если нужно историю изменений одной записи отобразить?

А не только конкретное состояние

Прочитал без снапшота

Тогда нужно опять фолдить?

Очевидно да

И теперь представь, что такое приходится делать раз в месяц

Ну аналогичное

:)

Да хоть 100 раз день

Так у тебя будет всё на костылях работать

И ты просто запутаешься

Ты слабо представляешь как это работает и почему это работает быстро

Ну не знаю, мне кажется это будет трэшем

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

Снапшоты нужны чтобы сервис можно было не держать в памяти и вырубать. Он потом восстановится

Если держать их онлайн то там скорость доступа моментальная

Или вот, чем я сейчас занимаюсь. Часть деталей было добавлено в один документ, а оказалось, что их нужно было добавить в другой документ, и мне нужно просто в базе ID документа поменять у детали, и всё

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

как-то с одной стороны всё должно быть в ивентах, а с другой данные изменяются и появляются как бы из ниоткуда 🤔

Как быть с ивентами?

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

Это все евенты. Делаешь сервис для мануального апдейта. Другой читает как свой стрим, так и твой. Подписка на две очереди. Агрегирует оба два

Это все евенты. Делаешь сервис для мануального апдейта. Другой читает как свой стрим, так и твой. Подписка на две очереди. Агрегирует оба два

И это отдельно кодом писать надо?

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

И это отдельно кодом писать надо?

Ну это ж микросервисы. Строчек 50

Ну это ж микросервисы. Строчек 50

Ну такое переодически приходится делать

Проще ID в базе поменять

Проще ID в базе поменять

Так начинается боль.

Так начинается боль.

В чём?

Проще ID в базе поменять

а как потом найти, кто и почему это сделал?

а как потом найти, кто и почему это сделал?

Именно

а как потом найти, кто и почему это сделал?

Так я сам делаю это руками

Юзеры не имеют к этому доступа

Хотя можно сделать так, чтобы они меняли, просто интерфейс надо пилить)

И это будет нормально работать, так как всё логируется

Я думаю тебе надо и дальше юзать реляционку. Это серьезный совет без сарказма

И это будет нормально работать, так как всё логируется

я думал что одно из требований - видеть историю изменений

как это будет происходить? расковыривалка логов?

я думал что одно из требований - видеть историю изменений

Так будет видно

У тебя есть деталь, по ней хранится вся история

В том числе, какому документу и когда она принадлежала

И кто когда вносил изменение

а вот этот момент со сменой ID документа

или это какой-то хак, о котором никому не нужно знать?

Это они накосячили просто)

И добавили не в тот документ

И мне нужно поменять это значение в самом логе