Можно использовать 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 часа или через сутки.
1) Это необходимо. В конечном итоге ты все равно знаешь какие поля должны быть для конкретного действия. Например при использовании методов create и update если в all придут какие либо другие данные то выдаст ошибку что не знает куда запихнуть эти новые поля.
Или например такая ситуация:
Из пользовательского фронтенда можно создать пользователя но тк это возможно и из админки с применением "isAdmin" то при $request->all() пользователи смогут отправить поле isAdmin и сделать себя админом. Такие случаи надо сразу отсекать т.к. в дальнейшем можно запутаться или забыть про это. Оставляешь только нужные для действия поля и нет проблем.
3) АА я понял то есть если в базе раньше было 1 а при update не пришло поле то надо его сделать 0.
Сделал так. значит наверно и вправду было дело в том что не выполнялся роут
$scope.$on(
"$routeChangeSuccess",
function ( event ) {
$scope.route1 = $route.current.params.text;
все равно не понимаю. в route2 содержится и отображается объект с данными однако значение с него не берет. но ведь факт того что он уже там есть значит что контролер отработал после роутера. можно попробовать по другому. добавить $route (в этом объекте уже есть все нужные значения) , в нем 2 объекта первый routes второй current (нужный объект в котором уже есть необходимые значения). так вот. если выводить $route.routes то выводится объект а если $route.current то undifined хотя он присутствует в $route.
там очень простая система темплейтов все задается в настройках категории, а сами шаблоны обычный хтмл + теги которые описаны в документации дле. просто береш нужный тег и вставляешь в хтмл
https://lumen.laravel.com/docs/6.x/mail
в пункте Usages написано буквами что надо смотреть документацию Laravel, разница только в конфигурации.