у тебя есть таблица на 10 полей. юзер прислал 5

если это нормальный кейс - у меня возможно не будет таблицы на 10 полей

а будет 2 таблицы по 5 полей.

в типичной ситуации это условно значит что 1 id, 4 меняем, 5 не трогаем

а может будет таблица на 10 и два VO

в типичной ситуации это условно значит что 1 id, 4 меняем, 5 не трогаем

?

типа делать diff предлагаешь?

ах вон в чём заморочка

обычно меняется то что пришло новое

если там пусто - удаляем. если ключа не пришло вообще - значит он не изменился

ты описываешь классический CRUD

в тч

но круд без БЛ

а я про БЛ

могу ли я описать твою БЛ как такой вот пайплайн: data -> process() -> data* -> save in elastic

я не столько про тендеры в эластике...

и еще момент - поскольку источник данных это парсинг сайтов - как ты узнаешь об изменениях? я правильно понимаю что ты делаешь diff?

если что

я не столько про тендеры в эластике...

нет, ты столько про тендеры в эластике

упростил же задачу

ты распинался про это дохера сообщений

там много прикладного

там много прикладного

давай другой пример

у тебя есть таблица на 10 полей. юзер прислал 5

вот же

что-то что ближе предметным областям с которыми я работал

вот же

что это за поля?

who cares

вот, в этом и проблемы) тебе не должно быть плевать)

ну то есть есть ситуации когда пофиг

или непонятно

пусть мне плевать )

но если тебе плевать - то и разговора нет

ты просто начнёшь предллагать декомпозицию

а задача всё равно останется

ибо в этом случае любая аргументация будет сводиться "мне пофиг"

да хоть бы товар в екомерсе

ну серьёзно, пофигу

да хоть бы товар в екомерсе

ну давай товар в ecommerce

как ты отнесешься к тому что я продукт разделю на 10 таблиц?)

одна для прайсинга, другая для скидонов, третья для деталей, четвертая для характеристик, ну и т.д.

пожалуй я вынужден отказаться от ваших услуг

пожалуй я вынужден отказаться от ваших услуг

вот я привел пример разделения. Что тебя тут не устраивает и чем ты это аргументируешь кроме "мне пофиг на данные"?

скидон не сущьность товар

оном может быть и на группу и на ссылку

оном может быть и на группу и на ссылку

может, в этом случае скидка будет некой спецификацией

другой пример

10 таблиц не 4

ну предположим

10 таблиц не 4

ну давай 4-5 табличек, у меня больше небыло для продукта

суть ззадачи не изменилось

надо по апи, предположим, изменить в 1 таблице 4 значения из 10

связанность изменилась. У нас есть один продукт с которым мы работаем в разных контекстах, с точки зрения разных заинтересованных сторон

надо по апи, предположим, изменить в 1 таблице 4 значения из 10

ну давай

промотай на 10 мин вперёд позязя

)

скажем поправим характеристики продукта

как с точки зрения пользователя в твоем варианте выглядит изменение 4-хе полей из 10-ти?

у него в форме загружены все 10 полей или он как-то по другому "изменяет" данные?

1. внешний API 2. поштучное изменение поля(придёт 2 поля из 10 где 1 pkey) 3. админка с массовыми действиями

1. внешний API 2. поштучное изменение поля(придёт 2 поля из 10 где 1 pkey) 3. админка с массовыми действиями

json patch

окей

патч = сет но с проверкой на доступ как для сущьности так и для полей

речь идет только об изменениях характеристик и в данном случае - мне пофигу)

пусть себе сэтит

можно ли отказаться от сет? ну конечно. назвать его по другому

суть в том что ту часть где пофигу я явно отделил от всего остального "продукта"

речь идет только об изменениях характеристик и в данном случае - мне пофигу)

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

и могу хоть в VO это завернуть и добиться имутабельности, а могу по простецки

ERROR: S client not available

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

зачем запрещать?

ну а чё бы нет

1. изменения не влияют на существующие заказы 2. ревизионирование

поменял вес - пересчиталась стоимость доставки

в чем проблема

эээ какой

цена например

ещё проще

цену в заказе менять нельзя

можно отказать в продаже, но менять нельзя

цену в заказе менять нельзя - но мы и не заказы редактируем

и даже не цену

или по таймауту

так прод может изменить цену товара продать подельнику вернуть как было

можно отказать в продаже, но менять нельзя

для этого надо просто механизм диспьютов ввести

усложнения

проще запретить

проще запретить

а если прод ошибся и надо поменять?

точнее разрешить только некоторым

как клиент твоей системы я скажу что "чет у вас гнилой сервис"

а если прод ошибся и надо поменять?

ну заказы менять нельзя как бы. можно отменить. я не знаю запрещено это или нет но так принято

точнее разрешить только некоторым

что за неравноправие? на основании каких критериев ты будешь решать кому можно а кому нет?

можно передобавить товар в заказ

ну заказы менять нельзя как бы. можно отменить. я не знаю запрещено это или нет но так принято

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

можно передобавить товар в заказ

нельзя

что за неравноправие? на основании каких критериев ты будешь решать кому можно а кому нет?

на основе бизнеса? :)

ну то есть можно

на основе бизнеса? :)

ну вот у меня вопрос к бизнесу - ответь на него

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

ну это и не правильно особенно для тог очто уже продано(бабло получено)

можно передобавить товар в заказ

ну то есть это к вопросу о диспьютах когда есть третья сторона которая такое сможет вручную разрулить

ну это и не правильно особенно для тог очто уже продано(бабло получено)

что не правильно?

разрулить это усложнение