Тебя повысили уже?

Я уже не работаю там х)

Я решил это время на шлюх тратить ? Ты хуевый

Лол, сначала обиделся и кинул меня в ЧС, потом вытащил обратно, теперь опять начинаешь.

в компилируемых языках тоже есть ограничения на инт... гавно гавняное

Если с нуля, то года 3. По 2-3 каждый будний день

А если каждый день по 5 чиса занятия

А если каждый день по 5 чиса занятия

Столько не получится. Все равно будешь отвлекаться на все подряд. Поэтому я взял в среднем.

Да и мозгам нужно время отдыхать, переварить все

Рахмат

Столько не получится. Все равно будешь отвлекаться на все подряд. Поэтому я взял в среднем.

Ну первый год не получится, но потом проще станет и можно вообще как рабочий день.

Думаю, многие стыкались с проблемой, когда есть таблица, в ней ячейки, и с некоторыми этими ячейками связаны данные из другой таблицы. К примеру: таблица order, и есть таблица order_api — т.е. заказы, которые передаются по api, а есть ручные заказы, которые не хранятся в таблице orderApi. Соотвественно, на view/update мы хотим получать данные и order, и если заказ по order_api — также информацию, которая хранится в этой табличке, чтобы не бегать. Но как с теми заказами, которых нет в order_api? Решаем всё if/else или есть более элегантное решение?

Думаю, многие стыкались с проблемой, когда есть таблица, в ней ячейки, и с некоторыми этими ячейками связаны данные из другой таблицы. К примеру: таблица order, и есть таблица order_api — т.е. заказы, которые передаются по api, а есть ручные заказы, которые не хранятся в таблице orderApi. Соотвественно, на view/update мы хотим получать данные и order, и если заказ по order_api — также информацию, которая хранится в этой табличке, чтобы не бегать. Но как с теми заказами, которых нет в order_api? Решаем всё if/else или есть более элегантное решение?

хранить все заказы в одной таблице, и добавить поле, которое будет отвечат за тип заказа - обычный, через апи, ручной

хранить все заказы в одной таблице, и добавить поле, которое будет отвечат за тип заказа - обычный, через апи, ручной

Это я сделал. Теперь вопрос в том: как выводить, к примеру, на DetailView. Допустим, попался заказ, который не по API, но в аттрибутах мы же указали, к примеру, api_id, который хранится в order_api. Я думаю, в данном случае лучше сделать дополнительный DetailView, и если заказ по API — он будет выводиться. Но есть ещё другой вопрос, более сложный:

К примеру, у нас таблицы: - service - service_api Не каждая услуга может иметь свои настройки API, но каждая настройка API имеет свою услугу. Вот тут сложно в плане CRUD: как обойтись без JS здесь? Ну т.е, допустим, можем сделать сразу вывод всех полей и, полей для API - таким образом, при сохранении будут идти данные с двух таблиц. Но если эта услуга не имеет настроек API — тогда как-то поля нужно эти игнорировать и сохранять её, как ручную. Пока с идей: сделать форму, и если услуга не имеет настроек API — пускай эти поля попросту не заполняются, а там уже на back'е проверяем, если поля незаполнены - обычная услуга, если заполнены - API.

Это я сделал. Теперь вопрос в том: как выводить, к примеру, на DetailView. Допустим, попался заказ, который не по API, но в аттрибутах мы же указали, к примеру, api_id, который хранится в order_api. Я думаю, в данном случае лучше сделать дополнительный DetailView, и если заказ по API — он будет выводиться. Но есть ещё другой вопрос, более сложный:

если ты это сделал, то таблицы order_api вообще быть не должно, одна таблица будет для заказов. а для фильтрации можно использовать модель search, которая генерируется в crud

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

если ты это сделал, то таблицы order_api вообще быть не должно, одна таблица будет для заказов. а для фильтрации можно использовать модель search, которая генерируется в crud

Видимо, я не совсем верно объяснил: Таблица order имеет поля, к примеру: id, service(&), user(&), cost, quantity, date, type(handle, api). Таблица order_api имеет поля: order_id(&), remote_order_id(ID удаленного заказа) — она нужна для того, чтобы не нарушать нормализацию, ибо не каждый заказ может быть по API.

Видимо, я не совсем верно объяснил: Таблица order имеет поля, к примеру: id, service(&), user(&), cost, quantity, date, type(handle, api). Таблица order_api имеет поля: order_id(&), remote_order_id(ID удаленного заказа) — она нужна для того, чтобы не нарушать нормализацию, ибо не каждый заказ может быть по API.

если в order_api нет ничего, кроме айди внешнего и айди заказа, почему айди внешний не внести в таблицу с заказами? Null если его нет, и номер если есть

если в order_api нет ничего, кроме айди внешнего и айди заказа, почему айди внешний не внести в таблицу с заказами? Null если его нет, и номер если есть

Ну это как-то неправильно, нормализацию же нарушает :(

->with('order_api') (или как там называется связь) и добавляешь в грид поле order_api.remote_order_id

И кому хорошо от этой нормализации?)

->with('order_api') (или как там называется связь) и добавляешь в грид поле order_api.remote_order_id

А что, если заказ не API и подобной информации нет?

А что, если заказ не API и подобной информации нет?

будет null

пустое поле

Ну это как-то неправильно, нормализацию же нарушает :(

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

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

ну если там не 20 полей, а одно

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

Ну думаю да, пойду на сделку с совестью

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

Ну думаю да, пойду на сделку с совестью

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

ну на AR запрос я сделаю интересует именно вопрос как полученные данные в модель получить и как их лучше хранить просто Public поля сделать и не париться или можно сделать вложенную модельку?

Если атрибуты в бд считаются и их нужно только вытащить в activerecord, то publicроля вполне нормальное решение

о. епрст, наконец я вас нашел. этот гиттер меня заколебал))

Я сначала прочитал Гитлер заколебал

Чуть не зиганул

секретный чат))

тоже прочитал гитлер и таки зиганул

@devium спалил я тебя

Ку всем, кто юзает ckeditor для yii2, вы не знаете какими параметрами задать стили для div'a окна редактора?

echo $form->field($model, 'content')->textarea()->widget(CKEditor::className(),[ 'editorOptions' => [ 'preset' => 'basic', //разработанны стандартные настройки basic, standard, full данную возможность не обязательно использовать 'inline' => false, //по умолчанию false ],

Ребята, извините что не по теме. Есть какой нибудь способ запустить расширение хрома из selenium?

Ку всем, кто юзает ckeditor для yii2, вы не знаете какими параметрами задать стили для div'a окна редактора?

Если это в компетенции php то продебаж, хотябы тем же xdebug) хотя лучше просто исходники почитать

Там есть что-то с фреймом связано, опция

Опять же, смотря что ты там юзаешь

Ребята, извините что не по теме. Есть какой нибудь способ запустить расширение хрома из selenium?

Хромдрайвер, если правильно понял твой вопрос

Да хромдрайвер

Ребята, а у всех миграции трансакциями нормально работают?

У меня че-то нифига, если ошибка - так не возвращется ничего назад

Что-то я где-то слышал что миграции не оборачиваются в транзакции

Зашибись, а зачем тогда safeDown и safeUp?

Должно ж работать, судя по документации

Или это у меня только? Просто вроде ж там ничего сложного, должно бы работать

Не все базы данных поддерживают транзакции для DDL, думаю проблема в этом

Если это в компетенции php то продебаж, хотябы тем же xdebug) хотя лучше просто исходники почитать

Ну если кто-то уже делал это пускай скажут

Я отсюда и узнал о скедиторе

Ребята, а у всех миграции трансакциями нормально работают?

С индексами и ключами не работает как минимум. А в простых вроде без проблем

Аааа

Я не знал

У меня MySQL, если что

И еще AI в мускуле независимо от транзакции инкрементирует/

Бывает.

Нукто тебя здесь за это не осудит

Ну если кто-то уже делал это пускай скажут

Может просто посмотреть самому? Зачем искать тех кто уже посмотрел?

Может просто посмотреть самому? Зачем искать тех кто уже посмотрел?

Я хз че и как смотреть

Есть тут, кто хорошо RBAC шарит?

Вопрос-то какой?

Не совсем понимаю по наследованию: допустим, есть такой код: $auth->addChild($role, $permission); Если проверяется правило, рбак сначала смотрит не на него, а на родителький пермишн/элемент, а уже потом на сам пермишшн? И так по всей иерархии? Или как?

Эээ, а разве так можно?

Потому как с наследованием ролей понятно - родитель может все. что могут потомки. А с правилами не совсем - родитель может все правила?

Можно точно

В доке ж написано - пермишшн должен быть унаследован или от роли, или от другого пермишшна

По крайней мере, я так понимаю

То есть, проверка идет по иерархии сверху вних, пока не будет первого попадания?

Подразумевается, что пермишшны имеют правила

Извиняюсь, там должен быть пермишшн, а не правило) Запутлася)

В addchild передается item, а rule не является потомком item

Ну вот да)

Наследование также как в ролях, просто если у пермишена есть правило - оно будет отраьотано

Отредактировал, чтоб понятно было

С правилом понятно, это как бы одно целое с пермишшном

Правило работает на пермишен

Да

Я просто в наследовании немного путаюсь

Когда нет правил понятно наследование?

Если есть, допустим, два пермишшна, с правилами, и должен сначала проверятся первый, а потом второй, то второй должен быть унаследован от первого, или наоборот?

Когда есть правило у пермишена, то оно всегда отрабатывает и если будет false, то считай, что у сотрудника нет этого пермишена

Когда нет правил понятно наследование?

Если по простому - есть роли, у них есть пермишшны, то да. А вот если некоторые пермишны при этом наследуютс еще друг от друга - тогда не совсем понятно

Также как роли с пермишенами)

Ровно также самая логика

Ето если простая иерархия, тогда да, понятно

Что значит сложная иерархи? Когда несколько наследников?

Когда у пермишшна, например, два предка

Хотя. я кажется начинаю понимать

Есть роль у нее может быть много прав, у каждого из прав ещё куча прав

Да. но если право иммет больше одного прдка. тогда как?

Так же может быть

Нарисуй дерево и тогда сразу понятно. Я всегда rbac паралельно визуализирую