VS
Поэтому и ищу решение , как можно написать в билдере join с avg чтоб жадной загрузкой не тянуть на 10 000 сервисов с 1млн коментов ради одной цифры
Size: a a a
2021 September 03
A
Если я правильно понял вам нужно бить запросы на chunk и считать ручками avg
VS
Имеешь ввиду мапить уже готовую коллекцию ?
?
Мапить коллекцию такое себе, нужно делать это средствами sql
A
Именную в виду получать кусками данные считать и так далее
VS
Так я мог сделать и сам , просто много лишних запросов в базу
VS
Я думал кто то подскажет хотя бы формат join'a чтоб дальше билдер можно было модифицировать
2021 September 04
B
чуваки, вы наверняка в курсе. Есть опубликованный кастомный докер контейнер, как его разобрать, чтобы увидеть конфиг из которого он изначально был собран?
?
Docker inspect?
Docker history?
Docker history?
ПЕ
Код модели покажи
AI
Как вывести sql форму запроса $user->posts()->count()?
VS
->toSql()
AN
Это не то, он выведет запрос с плейсхолдерами
🎃
DB::enableQueryLog() DB::getQueryLog()
AN
Вариант, оно покажет и запрос и значения
AI
да, спасибо )
AI
Недавно, кстати, обсуждали про хранение отношение в json или в отдельной таблице.
Абсолютно точно отдельная таблица, потому что это позволило мне одновременно и решить проблему с правами. Может, кому-то такое очевидно, но я очень сильно пропёрся ) Реализация такая:
Есть модель User. Есть Course. И есть модели StudentOfCourse, AuthorOfCourse, EditorOfCourse.
Каждая такая модель - это обычная pivot-таблица с user_id и course_id, например. Но в ней есть и свои поля, специфичные для этой роли.
В User прописаны отношения типа:
$user->studentsOfCourses(), $user->authorsOfCourses() и т.д.
Поверх каждого отношения описана обвязка $user->studentOfCourse(1), $user->authorOfCourse(1), которая возвращает экземпляр ну или null.
Собственно, крутость в том, что проверка прав и т.д. происходит просто за счёт наличия отношения:
public function update(Course $course) {
if($user->authorOfCourse($course->id)) {
$user->authorOfCourse($course->id)->doUpdate()
Еще большая прелесть в том, что т.к. эти пивоты обычные модели, у них могут быть и свои релейшены. Например
$user->teacherOfCourse(1)->students()
Как-то так ) Круто же? Или есть какие-то минусы такой реализции?
Абсолютно точно отдельная таблица, потому что это позволило мне одновременно и решить проблему с правами. Может, кому-то такое очевидно, но я очень сильно пропёрся ) Реализация такая:
Есть модель User. Есть Course. И есть модели StudentOfCourse, AuthorOfCourse, EditorOfCourse.
Каждая такая модель - это обычная pivot-таблица с user_id и course_id, например. Но в ней есть и свои поля, специфичные для этой роли.
В User прописаны отношения типа:
$user->studentsOfCourses(), $user->authorsOfCourses() и т.д.
Поверх каждого отношения описана обвязка $user->studentOfCourse(1), $user->authorOfCourse(1), которая возвращает экземпляр ну или null.
Собственно, крутость в том, что проверка прав и т.д. происходит просто за счёт наличия отношения:
public function update(Course $course) {
if($user->authorOfCourse($course->id)) {
$user->authorOfCourse($course->id)->doUpdate()
Еще большая прелесть в том, что т.к. эти пивоты обычные модели, у них могут быть и свои релейшены. Например
$user->teacherOfCourse(1)->students()
Как-то так ) Круто же? Или есть какие-то минусы такой реализции?
AI
Туда же идут, например, studentOfCourse и studentOfLesson и в колонках этой таблицы хранится уже кастомная инфа (типа прогресс курса, выполненные задания и т.д.)
AI
Ну и дополнительная плюшка, что все роуты очень красиво по ресту раскидываются ) практически нет кастомных экшенов
Р
Прикольно