Или я не правильно тебя понял

а, это я хрен знает, не пользовался

я в целом говорю про суть ошибки

Привет, как правильно отфильтровать коллекцию eloquent? Мне нужно сравнить значения по getKey() элементов коллекции с другим элементом вне обратной функции

$postId = $post->getKey(); $categoryPostsFiltered = $categoryPosts->filter(function($item, $postId) { return ($item->getKey() > $postId); })->all();

этот код не работает, но если установить больше 2 например внутри функции - срабатывает.

$categoryPostsFiltered = $categoryPosts->filter(function($item) use ($postId) { return ($item->getKey() > $postId); })->all();

огромное спс понял как пользоваться такими функциями

👍

Всем привет. Кто-то делал авторизацию через ЕСИА? Не знаете, где личный кабинет разработчика, где можно создать AppID для oAuth/openID аутентификации/авторизации?

Всем привет. Кто-то делал авторизацию через ЕСИА? Не знаете, где личный кабинет разработчика, где можно создать AppID для oAuth/openID аутентификации/авторизации?

там вроде с подачи документов надо начинать https://habrahabr.ru/company/cloud4y/blog/344964/

там вроде с подачи документов надо начинать https://habrahabr.ru/company/cloud4y/blog/344964/

Спасибо за ссылку

Думал у них как в вк, все просто

Да нефига подобное. Одно время только органы власти имели к апи доступ, так геморроя еще больше было

мы для органов власти и делаем

только что-то никто даже сконтачить не может) как будто не заинтересованы

Раньше руководитель (мэр, начальник омс и т.д.) должен подписать особую форму и выслать. Но сейчас наверное все по-другому...

Так, вопрос пиздец на 1000000

У меня attmpts растет бешено

Через что он ограничивается? —tries не помагает

Ребят, вот допустим есть таблица с заказами и у заказов есть статус. И есть таблица статусов заказов (типа lookup table) Можно сделать ее так: id, name, какие_то_дополнительные_поля. Где Id - primary key. А можно сделать primary key name. В чем разница и какой подход лучше?

Ребят, вот допустим есть таблица с заказами и у заказов есть статус. И есть таблица статусов заказов (типа lookup table) Можно сделать ее так: id, name, какие_то_дополнительные_поля. Где Id - primary key. А можно сделать primary key name. В чем разница и какой подход лучше?

для статусов обязательно отдельная таблица нужна? нельзя их в структуре таблицы заказов реализовать в виде ENUM?

другими словами "перечень статусов заказов может часто меняться?"

После того как долго этот вопрос гуглил, считаю что enum зло) но конкретно в моем случае там не совсем статусы, это я для примера привел, и к этим “статусам” еще прицепляется дополнительная информация

так делай по id, в чем проблема

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

вот эта статья расставит все точки на и: https://habrahabr.ru/post/107834/

если tl;dr то - суррогатные ключи это плохой дизайн базы данных

ох, сколько статей столько и мнений, если честно)

Щас поясню с чем столкнулся. У меня есть заказ, и у него есть тип: видео съемка, фото съемка. Тип съемки - таблица отдельная. Мне нужно в правилах валидации прописать: требуется указать количество фото если тип съемки - фото съемка. Если я храню все по id, то я не хочу и не могу делать так: photos_num: required_if:type_id,5 . Потому что айдишники могут сменится Вот поэтому подумал что по id в данном случае плохо

ох, сколько статей столько и мнений, если честно)

слушай ну там речь об "отцах основателях" типа Edgar Codd-а

они как бы разрабатывали эти концепции и к ним стоит прислушиваться

Ну это холиварная тема… Мне щас не важна правильность, но в данном случае делать required_if по id, это совсем плохо

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

а они против enum ниче особо не имеют

а я даже миграцию сделать не смог из-за енама в свое время

но если у вас конечно там много данных во второй таблице еще...

столько гемора было)

?

а заказчики меняют поля каждую неделю, по понедельнкам)

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

ошибку давал какой то пакет или типа того

http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

ну и тоже мнение

понятно.

но это все пофиг, просто я так понимаю с id я свою задачу в принципе не решу

хм

я так и не понял в чем задача

расскажи больше

валидация сложная?

Ты создаешь заказ. Либо фото либо видео. Если создал фото, ты обязан передать количество фото Есть таблица order_types, в коотрой лежат типы заказа (id, name) и значения 1, photo; 2, video Как мне сделать валидацию? ‘photos_num’ => ‘required_if:order_type_id,1’? Проверять по айдишникам? )

ну соотвественно фронт получает словарь типов заказов как id, name. Это если с суррогатными ключами

точнее даже не id, name а id, title, где title - то что выводит фронт

вот это я так понимаю косячная схема)

понял тебя; не хочешь в таблице с типами хранить необходимое количество ?

а сорри

не так прочитал

ага)

ну логичный вариант делать bool значение "надо ли передавать количество".

у тебя кроме фото и видео будет появляться потом еще что-то

а куда bool вставлять? не совсем понял

1,photo,true 2,video,false

но это пздц)

нене

я бы использовал енум)

а чем не подходит table inheritance?

от него наследуется photo order

video order

1) Енум не пойдет точно, потому что у типа заказа еще есть дополнительные поля 2) true/false не понял, с фронта приходит order_type_id скажем, и все. Как провалидировать?)

а чем не подходит table inheritance?

это когда несколько моделей одну табл используют?

нет, есть базовый ордер, от него наследуются фото и видео

это позволит тебе каждый заказ развивать отдельно

Я думаю просто вместо id сделать первичным ключем name, и тогда “required_if:order_type_name,video” и все окей

но по первости это кажется замороченно

но добавит гибкости, если разберешься

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

тогда делай, как привычнее)

Я почему вопрос спросил по id vs name as primary key, мне кажется в этой ситуации как раз самое оно заюзать name как ключ

ибо с id как то убого

просто помню что какие то минусы были у этого метода