АЯ
но как это технически реализовать... каждая сущность должна сначала помечаться на удаление, должна знать, что прилетит событие об успешном удалении файлов и после этого окончательно удаляться?
ну можно и так вполне.
Size: a a a
2020 October 20
СП
ну можно и так вполне.
тяжко)
АЯ
ну тода перед удалением можно почистить файлы
АЯ
и если ок - удалть сущность
СП
В целом понятно... магии не бывает и механизм надо продумать :)
АЯ
как KISS вариант если не заморачиваться и система простая.
главное ты эту операцию удаления куда-нибудь запакуй так чтоб снаружи никто не знал, как оно работает внутри.
это потом тебе при необходимости позволит изменить схему удаления
главное ты эту операцию удаления куда-нибудь запакуй так чтоб снаружи никто не знал, как оно работает внутри.
это потом тебе при необходимости позволит изменить схему удаления
SP
лучше с позиции "что-то пошло не так" рассуждать.
SP
но идея о том что бы операции через очередь с ретраями пускать хоть и красивая - для этого надо иметь готовую инфраструктуру. Без нее больно. Если у тебя уже какой nservicebus есть то да изи бризи но и вопросов этих у тебя тогда не будет
СП
но идея о том что бы операции через очередь с ретраями пускать хоть и красивая - для этого надо иметь готовую инфраструктуру. Без нее больно. Если у тебя уже какой nservicebus есть то да изи бризи но и вопросов этих у тебя тогда не будет
retry - это когда что-то пошло не так, то будет повторное выполнение?
СП
У меня есть простая очередь на базе БД)
SP
retry - это когда что-то пошло не так, то будет повторное выполнение?
в nservicebus за счет этого решаются вопросы "как обеспечить последовательность действий". Мол ты кинул сообщение "пользователь зарегался" и сначала надо создать его профиль а потом уже к профилю вещи привязывать. И если с чем-то пошло не так (профиль не успел создаться) то операция тупо зафэйлится и "попробуем потом"
DT
звучит как сага
СП
Я думаю все таки хранить к подобным записям id объекта владельца и тип объекта владельца. Не делать на них ключи, ничего. Использовать это только на случай, если вдруг что-то пошло не так и надо узнать что эта запись
˸A
:)
Возник ещё вопрос ))
Допустим есть система с кучей модулей.
Мы делаем модуль "файлы", который позволяет хранить файлы.
Работает это так: любой другой модуль может закинуть файл в модуль "Файлы", получить ID файла, сохранить где-то у себя и потом по этому ID получить файл обратно.
И как бы всё норм.
Один момент смущает: по файлу нельзя понять кому он принадлежит и можно ли его удалить.
Допустим есть модуль Задачи, который работает с модулем Файлы. Произошёл какой-то сбой и при удалении задач не делался запрос в Файлы на их удаление. Я же потом никак не узнаю, что какие-то файлы ни к кому не привязаны и можно их снести.
Как вообще такой момент решается? Хранить в модуле файлов какой-то список с типам и id объектов которым принадлежат файлы... что-то мне кажется это не правильно.
Возник ещё вопрос ))
Допустим есть система с кучей модулей.
Мы делаем модуль "файлы", который позволяет хранить файлы.
Работает это так: любой другой модуль может закинуть файл в модуль "Файлы", получить ID файла, сохранить где-то у себя и потом по этому ID получить файл обратно.
И как бы всё норм.
Один момент смущает: по файлу нельзя понять кому он принадлежит и можно ли его удалить.
Допустим есть модуль Задачи, который работает с модулем Файлы. Произошёл какой-то сбой и при удалении задач не делался запрос в Файлы на их удаление. Я же потом никак не узнаю, что какие-то файлы ни к кому не привязаны и можно их снести.
Как вообще такой момент решается? Хранить в модуле файлов какой-то список с типам и id объектов которым принадлежат файлы... что-то мне кажется это не правильно.
Вы изобретаете AWS S3?
МФ
звучит как сага
Process manager, оно и есть :)
VS
но как это технически реализовать... каждая сущность должна сначала помечаться на удаление, должна знать, что прилетит событие об успешном удалении файлов и после этого окончательно удаляться?
зачем вообще физически удалять файлы?
место жалко?
место жалко?
СП
зачем вообще физически удалять файлы?
место жалко?
место жалко?
Мм.. ну да) не хорошо же. Но вообще вопрос любых данных касается в подобной ситцации
AN
Добрый. Стоит ли делать контейнер для модуля? Или же сразу регать в контейнер аспа? (В рамках мироксервиса)
АГ
В целом понятно... магии не бывает и механизм надо продумать :)
сделай консольную команду, которая будет искать файлы в каталоге, для которых нет записей в БД, и периодически кидай кнопкой в админке заявку в очередь на выполнение этой задачи. она будет чистить брошенные файлы, статистику тебе где-нибудь о проделанной работе запишет.
АГ
Добрый. Стоит ли делать контейнер для модуля? Или же сразу регать в контейнер аспа? (В рамках мироксервиса)
как это модуль в контейнере? это уже микросервис какой-то получается. можно иметь в системе scheduler, т.е. консольную команду, которая запускается по крону каждую минуту, и если пришло время выполнять что-то, то создает форком отдельный процесс и выполняет это (дергает другие консольные команды, как самый ходовой вариант). да, под это отдельный докер контейнер сделать надо. а сам код в основном приложении.