Трейт в контроллер ?

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

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

может о разном. а можно примеры сложных выборок? «топ10 популряных новостей»? «последние новости на главную»? «форма поиска новостей»? именно выборка

Например выборка активности пользователя по определённым объектам, там 2 джоина, есть сырой запрос для выбора id, это все складывается в 1 коллекцию

Потому что она вечная)

Народ, всем привет!
Есть action , например, редактирования пользователя. Под него есть вюшка и форма редактирования. Если ошибка валидации формы - мы возвращаем пользователя на эту вюшку с подсветкой полей что не прошли валидацию. Тут все просто и понятно.
Вопрос:
А если на этой вюшке редактирования пользователя есть еще одна форма, например присвоение пользователю какой-то роли. Как писать логику вализации и записи данных с другой формы? Если использовать свой action, и вализацию не прошли на присвоение пользователю роли, то нужно вернуть его на эту вюшку, а это значит что нужно в этом экшене и предварительно и создать форму редактирования тоже, что бы потом ее отрендерить на вюшке... А если оставить все на одном экшене редактирования пользователя - то потом будет валидироватся сразу 2 формы при запросе редактирования пользователя.

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

Вчера увидел голосование но не мог ответить)) сегодня хочется похоливарить))
в общем смысл репозиторий в том что бы создать слой связывающий очеловечивающий работу с БД))
к примеру проект работает с БД не через ОРМ а через  запросы к СУБД..  мы делаем репозитории которые содержат методы get/create/update/delete и частные их случаи.. потом если нам надо заменить СУБД у нас в проекте просто заменяется драйвер БД а методы репозитория как мы юзали так и продолжаем юзать..
в общем репозиторий это очеловечивания работы с БД плюс возможность быстрой замены типа хранилища данных..
в ларке все это уже есть прям в Eloquent который реализует паттерн ActiveRecords...  
т.е. репозиторий в ларке становится по факту просто расширением модели AR в который удобно вынести бизнес логику из модели если модель становится толстая...  
плюс неоднозначное понимание паттерна репозитой... есть много мнений, одно из мнений говорит что репозиторий для извлечения данных, а сервисный слой для создания.. но при этом в проектах вижу что в репозиторий добавляют еще и создание...
когда я  делал свой велосипед то мой репозиторий и извлекал и создавал данные.. мне это показалось на тот момент правильным решением) сейчас у меня нет однозначного мнения по этому поводу))

про это и говорим) выходит все запросы идут через репозиторий?) вот прям все? Прощай DI моделей, прощай findOrFail или дублирования в своем классе? .

Репозиторий не создает и не удаляет, он добавляет или убирает из коллекции.

все по разному трактуют эту фразу))  но в целом - да -  репозиторий должен отдавать данные))

а я вчера не успел встрять в срач)) вот решил догнать))

Всем привет! Есть проблема с Redis. Он используется для броадкастинга и для очередей. Сокеты ходят через laravel-echo, приложение развернуто через laradock. Суть проблемы:
 Если из приложения получать список ключей из Redis, то возвращает ключи только для очередей. А если через redis-webui, то там только каналы присутствия (presence), а очередей нет. Но сокеты ходят и каналы присутсвия реагируют на пользователей, значит сам laravel-echo-server получает доступ и к ключам для очередей и presence. У меня развернулось 2 редиса? почему тогда laravel-echo-server имеет доступ к обоим? Кто подскажет куда копать?

laravel-debugbar под 7 Ларе работает? что-то под нее не могу запустить =/

работает

@perin тут скамер появился

Господа умные, не подскажете почему не работает такая конструкция?

$payment = Payment::firstOrCreate([
      'status' => 0,
      'user_id' => $user_id,
      'plan_id' => $plan_id,
      'description' => $plan->name,
      'paymentType' => $type,
      'amount' => $plan->amount,
    ], [
      'created_at' => $now,
      'updated_at' => $now,
    ]);

Конкретно что? Не обновляет дату создания и обновления

$payment = Payment::firstOrCreate([
      'status' => 0,
      'user_id' => $user_id,
      'plan_id' => $plan_id,
      'description' => $plan->name,
      'paymentType' => $type,
      'amount' => $plan->amount,
    ], [
      'created_at' => $now,
      'updated_at' => $now,
    ]);

в protected $fillable есть они ?

да