Антон Шелестов, теоретически подход твой верный и библиотека годная. Но в реальности надо использовать Middleware для этого а не параметры в роут передавать.
Я бы (лично мое мнение) посоветовал бы совместить с библиотекой laravel-actions а файл роутов оставить чистым и без любой логики.
Можно использовать uuid для исключения ситуаций прикрепления других файлов но еще нужно добавить крон задание на чистку тех файлов которые не дождались отправку через форму (брошенные формы)
Модно использовать один к одному через а в pivot таблицу добавить id но лучше сразу не простой индекс а строку uuid без дефисов (чисто как задел на будущее)
vism, Предлагаешь выполнять 10000 обновлений базы за раз? Если весь проект залепить "Hellow world" (читай как гавнокод) то потом нужна большущая лопата чтобы это все раскидать. Даже сам $model->update() не должен существовать в таком виде в разных частях проекта.
Любой проект должен изначально предполагать возможность модификации, есть у бабушки то о чем ты думаешь или нет. Рано или поздно придет заказчик и скажет что у бабушки это должно быть. А ты пойдешь перелопачивать тонну своих макаронин в поисках того что надо изменить, а потом еще несколько дней проверять везде ли заменилось и работает. ололо
lavren, еще лучше ставить себя же в очередь. И избавиться от чанков. Проверяешь есть ли более 50 записей ставишь их в очередь на обработку. И вызываешь этот же job еще раз из самого себя если записей 50, если записей меньше, то очевидно они закончились, просто ставишь их в обработку и больше не вызываешь этот job. Это исправит ситуацию которую описал человеки ниже.
vism, ну смотря что в твоем понятии "создать миллион job". А в целом да. Тебе надо поставить в очередь на выполнение миллион задач по обновлению данных. Потому что в рамках одного процесса миллион записей все равно не выполнит php. Сейчас у тебя в одном процессе, если 10000 записей надо обработать, 10000 update + 10000 / 50 get + все то время что тратится на выполнение функции обработки адреса. К примеру если изменится метод получения адреса (например по стороннему APi) то job начнет загибаться уже на десятке. Собственно очереди для того и придуманы чтобы не запускать такие обработки в одном процессе.
Мне кажется это достаточно спорный вариант. Тк он вызывает больше проблем в т.ч стили должны соответствовать общей стилистике приложения + производительность идет в низ т.к не нативное представление.
wisgest, Да, подозрительное письмо ставится в очередь на проверку. Я не знаю как они их дальше проверяют но такое письмо может прилететь через 2 часа или через сутки.
