ну то что ты скинул, там нет такого метода ;)

там есть __callStatic вы не заметили?

Всем привет. Подкинте чатик по JS пожалуйста

Всем привет. Подкинте чатик по JS пожалуйста

@js_ru

@js_ru

спасибо большое

в ларке то как раз просто. Проверяешь соответствия мыла активным пользователям

На уровне бд хотелось бы запретить, иначе что делать с параллельными запросами...

Через форму и постом или путом

Смотри var uluru = {lat:25,lng:54},и как в форму это записать ?

Через пост отправить

Смотри var uluru = {lat:25,lng:54},и как в форму это записать ?

Ну просто запихни это в value и сделай сабмит

Чо ты как ребенок

На уровне бд хотелось бы запретить, иначе что делать с параллельными запросами...

Не смотреть на софт делит. Поддерживать уник даже для удаленных. Ведь А что при восстановлении? Еще можно удалённому юзеру ставить префикс у мыла.

Не смотреть на софт делит. Поддерживать уник даже для удаленных. Ведь А что при восстановлении? Еще можно удалённому юзеру ставить префикс у мыла.

Ну скорее тут не для восстановления надо оставить, а для истории. Ну и да - пока префиксы фигачим, но не очень понравилось решение...

Посоветуйте альтернативу Laravel Cashier только под наш регион.

Ну скорее тут не для восстановления надо оставить, а для истории. Ну и да - пока префиксы фигачим, но не очень понравилось решение...

сама логика неправильная. т.е что будет, когда будет регаться новый с таким же мылом, ты будешь считать его за другого пользователя?) Хотя по факту это один и тот же) В-принципе, должна работать связка мыло + deleted_at на уровне базы, скорее всего неправильно что-то настроил. Но сама идея уже в корне не очень, имхо

сама логика неправильная. т.е что будет, когда будет регаться новый с таким же мылом, ты будешь считать его за другого пользователя?) Хотя по факту это один и тот же) В-принципе, должна работать связка мыло + deleted_at на уровне базы, скорее всего неправильно что-то настроил. Но сама идея уже в корне не очень, имхо

спасибо за логику, но это было требование продактов

спасибо за логику, но это было требование продактов

ну оно несет в себе кучу проблем в обозримом будущем. Историю можно реализовать проще)

Ну то есть совсеты не технические, а так делать не надо

окей

это мы прошли

уже сделано и нельзя по другому ?

Просто днем про null говорили и я хотел показать как null в ключах в mysql работает

Я знаю что они делают

ну и с email решили как Макс сказал ?

Gdpr

100%

Ну только мы это 2 года назад начали делать ?

Тогда еще мало об этом говорили ?

Ну только мы это 2 года назад начали делать ?

Так все начали :)

Но зачесались вот недавно

А так да ?

И это в том числе

Ну я бы конечно нулил email

Либо

Реплейсил его на что то типа some****user@*ail.com

Типа анонимизировал

Это скорее вопрос не технический

а разве по gdpr не нужно насовсем удалять данные о пользаке?))

А именно по бизнесу

а разве по gdpr не нужно насовсем удалять данные о пользаке?))

Нет

Подойдёт анонимизация данных

ну deleted_at точно не анонимизация :D

Тобишь удалить имя, телефон и email - достаточно

Тобишь удалить имя, телефон и email - достаточно

ну если нет еще каких-то данных по которым можно в итоге идентифицировать (всякие номера соц страх, карт и т.д и т.п))

ну если нет еще каких-то данных по которым можно в итоге идентифицировать (всякие номера соц страх, карт и т.д и т.п))

Ну да

Я не стал писать все:) это очевидно просто

Короче. Заменить все звёздами.

На 70%

И норм

Имхо

Но нужно у юристов узнавать

Всем привет! Искал способ отсортировать выборку по связанной таблице, нагугл вот такую штуку: https://stackoverflow.com/questions/25700529/laravel-eloquent-how-to-order-results-of-related-models там советуют поступать вот так: $school = School::with(['students' => function ($q) { $q->orderBy('whateverField', 'asc/desc'); }])->find($schoolId); Но у меня этот способ не работает. Таким макаром действительно можно сортировать выборку? Или отвечающий ошибся?

Всем привет! Искал способ отсортировать выборку по связанной таблице, нагугл вот такую штуку: https://stackoverflow.com/questions/25700529/laravel-eloquent-how-to-order-results-of-related-models там советуют поступать вот так: $school = School::with(['students' => function ($q) { $q->orderBy('whateverField', 'asc/desc'); }])->find($schoolId); Но у меня этот способ не работает. Таким макаром действительно можно сортировать выборку? Или отвечающий ошибся?

Ты, часом, не asc/desc вписываешь? Метод-то верно написан...

Всем привет! Искал способ отсортировать выборку по связанной таблице, нагугл вот такую штуку: https://stackoverflow.com/questions/25700529/laravel-eloquent-how-to-order-results-of-related-models там советуют поступать вот так: $school = School::with(['students' => function ($q) { $q->orderBy('whateverField', 'asc/desc'); }])->find($schoolId); Но у меня этот способ не работает. Таким макаром действительно можно сортировать выборку? Или отвечающий ошибся?

А как не работает?

Ошибка?

Какая?

Ты, часом, не asc/desc вписываешь? Метод-то верно написан...

Нет, вписываю asc )

Какая?

Ошибки нет, просто поиск происходит не верный (либо я чего-то не понимаю)

Ошибки нет, просто поиск происходит не верный (либо я чего-то не понимаю)

Ну а что там за sql на выходе?

Ну а что там за sql на выходе?

sql на выходе такой, как-будто бы сортировка и не применялась

$query->with(['author' => function($author) { $author->orderBy('id', 'asc'); }]); dd($query->toSql()); В sql коде сортировки нет

Как вообще работают подобные штуки? В какой момент применятся вещи указанные в callback? (Эх, с джойнами всё гораздо проще)

$query->with(['author' => function($author) { $author->orderBy('id', 'asc'); }]); dd($query->toSql()); В sql коде сортировки нет

Потому что ты сделал toSql для основного запроса. А тот что в with он порождает отдельный

Как вообще работают подобные штуки? В какой момент применятся вещи указанные в callback? (Эх, с джойнами всё гораздо проще)

Сначало выбираются данные для основной модели а потом грузятся указанные релейшены со своими доп ограничениями из замыкания

Сначало выбираются данные для основной модели а потом грузятся указанные релейшены со своими доп ограничениями из замыкания

Спасибо! То есть, отсортировать выборку таким образом не выйдет?

Спасибо! То есть, отсортировать выборку таким образом не выйдет?

Так сортируется именно связанные (тоесть сами авторы в вашем случае если бы их было много)

Ты хотел основную модель по связи сортирнуть?

Ты хотел основную модель по связи сортирнуть?

Так точно. В итоге сделал через join, но он ведь не учивает scopes

Так сортируется именно связанные (тоесть сами авторы в вашем случае если бы их было много)

Кажется стало проясняться в голове )

Так точно. В итоге сделал через join, но он ведь не учивает scopes

Ну у тебя сортировка же по id автора в примере (или в реале не так просто?) Просто это же поле есть у тебя в виде типо author_id Почему не по нему сортирнуть?

Ну у тебя сортировка же по id автора в примере (или в реале не так просто?) Просто это же поле есть у тебя в виде типо author_id Почему не по нему сортирнуть?

Всё гораздо интереснее, сортировка по ФИО автора )

Так точно. В итоге сделал через join, но он ведь не учивает scopes

Посмотри вот гист. Мб поможет сделать то что хочешь https://gist.github.com/Ellrion/5d873fc8acf4d18464e65595c84bc374

Ну, по имени, если точнее

Посмотри вот гист. Мб поможет сделать то что хочешь https://gist.github.com/Ellrion/5d873fc8acf4d18464e65595c84bc374

Спасибо

Какраз  ->orderByRelation('author', 'name') в заголовке)

Ага, увидел )

Вот только понять не могу, за счёт чего у тебя учитываются scopes связи? (Например, связанная сущность не активна и соотвественно в сортировке участвовать не должна) public function scopeOrderByRelation($query, $relation, $column, $direction = 'asc') { if (null === $query->getQuery()->columns) { $query->select([$this->getTable() . '.*']); } $relation = $query->getRelation($relation); $related_table = $relation->getRelated()->getTable(); //for laravel "< 5.4" //$query->leftJoin($related_table, $relation->getForeignKey(), '=', $relation->getQualifiedParentKeyName()); $query->leftJoin($related_table, $relation->getQualifiedForeignKeyName(), '=', $relation->getQualifiedParentKeyName()); foreach ((array) $column as $order) { $query->orderBy($related_table . '.' . $order, $direction); } return $query; }

Они не учитываются. А как скоуп связи влеяет на сортировку основной модели по этой связи?

Они не учитываются. А как скоуп связи влеяет на сортировку основной модели по этой связи?

Не учитывать soft_deleted сущности например, или скажем, какой-то собственный scope с критерием неактивности Получается, что если у основной модели нет связанной сущности, то и в сортировке она окажется в самом низу

Или, не знаю ) Почему-то заморочился по этой теме

Не учитывать soft_deleted сущности например, или скажем, какой-то собственный scope с критерием неактивности Получается, что если у основной модели нет связанной сущности, то и в сортировке она окажется в самом низу

Это да согласен. С этим беда)

Ну для простой сортировки имхо норм метод

Хай всем

Как в ларке сделать нормальныно уникальное мало, если пользователи могут удаляться?

если вопрос еще актуален то лучше сделать свой rule или validator

даже не «лучше», а это единственный вариант

Коллеги

Кто-нибудь имел дело с Django?

парни такое дело. есть список моделей на странице.. запросов выполняется около 8-9шт.. есть пагинатор... для страниц 2+ грузится моментально .. первая - жесткие лаги загрузка страницы 18сек

при этом дебаге отображает что запросы те же и каждый запрос в рамках 0.01-0.1с..

Кто-нибудь имел дело с Django?

https://t.me/django_framework

Кто-нибудь имел дело с Django?

спрашивай в личку, если тут нищя

спрашивай в личку, если тут нищя

Окей, спасибо