'title' => Schema::TYPE_STRING . '(100) NOT NULL', ?

счастья тебе, мил человек!

Работаем, братья

спасибо, то что нужно

не за что, обращайтесь

Могут быть разные настройки пхп на сервере для консоли и для апача например

Как их проверить?

помогите,как работает elasticSearch?

Гайз ,есть вопрос. Кто сталкивался с ddos приложения на yii2? Какая есть панацея кроме http://www.yiiframework.com/doc-2.0/yii-filters-ratelimiter.html Мож кто подскажет. Знаю, что сервер надо тюнить. Но там админы или пиздец ленивые или тупые... Надо решать как-то вопрос

Там рейт лимит по-умолчанию идет залогиненых юзеров, сделай просто по ip

И бан добавь, что если 5 рейтов поймал - бан 5 сек, еще 5 - умножай время бана на 5 Как нибудь так для начала

Бомбу можно попробовать скидывать. На хабре описание есть

Бомбу можно попробовать скидывать. На хабре описание есть

gzip-bomb?

Точно!

А чем она сопсна поможет

Прочитал) Веселая штука)

https://habrahabr.ru/post/332580/

Тополь М уже нужен ;)

Приветствую! Обновился с 2.0.12 на 2.0.13.1 и полетело расширение johnitvn/yii2-rbac-plus

При добавлении новой записи ошибка: Missing argument 1 for johnitvn\rbacplus\models\Permission::find(), called in \vendor\yiisoft\yii2\validators\UniqueValidator.php on line 210 and defined \vendor\johnitvn\yii2-rbac-plus\src\models\Permission.php и далее по стеку.

Приветствую! Обновился с 2.0.12 на 2.0.13.1 и полетело расширение johnitvn/yii2-rbac-plus

Приветствую. Держите вкурсе.

У кого работает это расширение в текущей версии, нужно что-то еще шаманить?

При добавлении новой записи ошибка: Missing argument 1 for johnitvn\rbacplus\models\Permission::find(), called in \vendor\yiisoft\yii2\validators\UniqueValidator.php on line 210 and defined \vendor\johnitvn\yii2-rbac-plus\src\models\Permission.php и далее по стеку.

так вряд ли речь про обновление

Missing argument 1 for johnitvn\rbacplus\models\Permission::find() ошибка не двусмысленно намекает на то что что-то не так

а именно на то что автора рожали стоя

Там с валидатором unique проблема, если я его убираю, то все работает. Но до обновления и так работало

ну так ты его сам добавил походу

короче дело не в бобине

Народ, не ради срача пишу, помощь логическая нужна. Пишу проект по принципам DDD. Нужно проверить, есть ли у пользователя активная подписка (сущность User, сущность Subscribe с полем userId). Пишу в SubscribeRepository метод existActiveByUserId(int $userId) : bool, где будет уже запрос в бд...но что - то мне подсказывает, что не репозиторий должен это делать. Но чья это зона ответственности? Репозиторий - хранилище, вроде коллекции. Пока писал - понял, что видимо сам юзер должен это знать, есть ли у него активные подписки. Вроде $user->isHaveActiveSubscribe() : bool. Если не прав - поправьте плз. P.S. Срач про надобность/ненадобность DDD просьба не разводить

Народ, не ради срача пишу, помощь логическая нужна. Пишу проект по принципам DDD. Нужно проверить, есть ли у пользователя активная подписка (сущность User, сущность Subscribe с полем userId). Пишу в SubscribeRepository метод existActiveByUserId(int $userId) : bool, где будет уже запрос в бд...но что - то мне подсказывает, что не репозиторий должен это делать. Но чья это зона ответственности? Репозиторий - хранилище, вроде коллекции. Пока писал - понял, что видимо сам юзер должен это знать, есть ли у него активные подписки. Вроде $user->isHaveActiveSubscribe() : bool. Если не прав - поправьте плз. P.S. Срач про надобность/ненадобность DDD просьба не разводить

репозиторий должен что-то достать из БД

а что говорит сервис

ну в сервисе и надо узнать

так сервис не знает что ему надо или как?

Знает, $subscribeService->subscribe(SubscribeForm $form) Сервис подписки

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

Кстати, еще вот такой вопрос: может ли репозиторий вернуть null вместо сущности? Repository->get(777)

или должен Exception выплюнуть, если записи запрашиваемой не существует?

Репозиторий что то достает из БД. Хорошо если это набор данных, не очень хорошо если одно конкретное поле

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

логика в сервисе - запросы в репе

или должен Exception выплюнуть, если записи запрашиваемой не существует?

от религии зависит. не вижу ничего зазорного в null для такого

логика в сервисе - запросы в репе

логика то в сервисе. Но не вся подряд логика. В сервисе логика задачи, которую решает сервис.

Имхо лучше null, а в сервисе на это проверять и кидать уже эксепшн

Нарвался на проблемы просто при выкидывании эксепшенов из репозитория

логика то в сервисе. Но не вся подряд логика. В сервисе логика задачи, которую решает сервис.

так бизнес логика.

я собственно вот почему спрашиваю https://github.com/ElisDN/yii2-demo-shop/blob/master/shop/repositories/Shop/BrandRepository.php тут эксепшены. Все, что тут делает метод get репозитория - это выкидывает эксепшн, если не найдена сущность. Т.е. эмуляция коллекции. Если ты обращаешься к несуществующему элементу коллекции, то ошибка.

Это не принципиально для репозиториев ПМСМ

Читабельней только

Ясно, спасибо!

Как их проверить?

Это уже к настройкам сервера...

я собственно вот почему спрашиваю https://github.com/ElisDN/yii2-demo-shop/blob/master/shop/repositories/Shop/BrandRepository.php тут эксепшены. Все, что тут делает метод get репозитория - это выкидывает эксепшн, если не найдена сущность. Т.е. эмуляция коллекции. Если ты обращаешься к несуществующему элементу коллекции, то ошибка.

ну и хз есть ли смысл скрещивать AR с repository

есть

есть

репозиторий поидее еще и кеширует все это )

я щас в проекте работаю, где кеширование AR это боль

имеется ввиду хранение объектов AR в памяти процесса

Это не принципиально для репозиториев ПМСМ

Поясню. Удобней ошибки обрабатывать в едином стиле. Экспешен кидае не локализованное сообщение, которое обрабатывает сервис и возвращает уже нужное.

но не 100% обязательно

т.е. тут ты бы грубо говоря sql составил бы, получил ответ, и с помощью гидрации создал бы сущность, которая не наследник AR?

ну и хз есть ли смысл скрещивать AR с repository

т.е. тут ты бы грубо говоря sql составил бы, получил ответ, и с помощью гидрации создал бы сущность, которая не наследник AR?

т.е. тут ты бы грубо говоря sql составил бы, получил ответ, и с помощью гидрации создал бы сущность, которая не наследник AR?

нее, репа поидее возвращает DTO

репозиторий возвращает сущность

агрегат

Domain Transfer Object оно возвращает

никакой не DTO

нее, репа поидее возвращает DTO

о срач....ддд репа возвращает любые данные главное что бы не привязывались к реализации

о срач....ддд репа возвращает любые данные главное что бы не привязывались к реализации

+1 DTO =)

о срач....ддд репа возвращает любые данные главное что бы не привязывались к реализации

этого я и боялся)))

AR это уже реализация

ERROR: S client not available

в контексте выше

т.е. AR модель которая может и сохранить и в горящую избу войти )

о срач....ддд репа возвращает любые данные главное что бы не привязывались к реализации

Хорошо. А кто тогда из возвращаемой репой DTO сотворит сущность?

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

Почему DTO? Че ж не сразу массив?)

Сорян

+1 DTO =)

Какая разница DTO или VA или не связанную с AR сущность ?

хоть коллекцию или массив возвращай.

главное не привязаваться к AR, DM, GW

главное не привязаваться к AR, DM, GW

Я плохо вербализировал.

Ты правильно говоришь

Какая разница DTO или VA или не связанную с AR сущность ?

Суть уловил. Но я приверженец возвращать именно "сущность", а не массив с DTO. Другое дело, что эта сущность зависит от AR...конечно чище было бы в таком случае использовать доктрину. Ну тогда зачем я вообще взял Yii2?) В свое оправдание скажу лишь, что AR мои сущности используют только в плане инфраструктуры, аля http://www.elisdn.ru/blog/109/domain-entities-active-record

Суть уловил. Но я приверженец возвращать именно "сущность", а не массив с DTO. Другое дело, что эта сущность зависит от AR...конечно чище было бы в таком случае использовать доктрину. Ну тогда зачем я вообще взял Yii2?) В свое оправдание скажу лишь, что AR мои сущности используют только в плане инфраструктуры, аля http://www.elisdn.ru/blog/109/domain-entities-active-record

DTO это не совсем массив. Это как вернуть текст ошибки или исключение.

DTO можно представить массивом (набором данных), но какой перед тобой массив ты не сможешь определить, а какой перед тобой класс сможешь. И это уже ООП

Ну тогда зачем я вообще взял Yii2? А это вопрос мучающий многих. В первую очередь, зачем ты взял PHP, во вторую уже все остальное.

Не важно лара, симфони или й. Все равно они на РНР )

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

Суть уловил. Но я приверженец возвращать именно "сущность", а не массив с DTO. Другое дело, что эта сущность зависит от AR...конечно чище было бы в таком случае использовать доктрину. Ну тогда зачем я вообще взял Yii2?) В свое оправдание скажу лишь, что AR мои сущности используют только в плане инфраструктуры, аля http://www.elisdn.ru/blog/109/domain-entities-active-record

там вообще теряется вся прелесть репозиториев. я про пример на сайте. это или переходной этап или автор что-то делает не то.

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

так прячут гидрацию то в репозитории

и мы знаем какой перед нами dto

так прячут гидрацию то в репозитории

именно, но гидрация внутри репозитория для того, чтоб создать сущность! Пример: У нас есть User, и чтоб его вытащить из допустим бд - нам надо запросить его из UserRepository, который вернет сущность (или агрегат) типа User. Допустим из UserRepository ты получаешь DTO, предварительно сгидрировав его внутри. Тогда для получения сущности User тебе надо из DTO выполнить вторую гидрацию, которая уже получается будет вне репозитория. Куда выносить тогда этот копипаст? Зачем усложнять этим себе жизнь, если репозиторий сразу может нагидрировать внутри User?

DTO настолько я понимаю нужен только если между слоями пирога надо передать данные

там вообще теряется вся прелесть репозиториев. я про пример на сайте. это или переходной этап или автор что-то делает не то.

Почему теряется? Там есть интерфейс репозитория конкретной сущности, имплементировать который может любая реализация. Считаю это как раз таки "правильным" репозиторием по DDD

Почему теряется? Там есть интерфейс репозитория конкретной сущности, имплементировать который может любая реализация. Считаю это как раз таки "правильным" репозиторием по DDD

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

и репозиторий возвращает AR

и мы передаем AR что бы сохранить его

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

Да, согласен, там есть у сущности инфраструктурная зависимость от AR, но это скорее компромис) В слое бизнес логики ты напрямую не дергаешь save() активрекордовский, а сохраняешь сущность через репозиторий, который по сути интерфейс. Тесты тоже AR не трогают, а тестируют лишь логические методы сущности. Чтоб избавиться от AR тебе надо убрать наследование, и удалить инфраструктурные методы типа afterFind()и прочие, которые по коду лежат рядом. Другое дело, что этот AR там осознанно, дабы скрестив ужа с ежом получить выгоды фич фреймворка, не размазывая логику приложения, а используя DDD. Я думал над тем, чтоб не использовать AR конкретно тут, хотел впилить Doctrine. Но решил, попробовать именно этот подход в этом проекте, хочешь не хочешь - а в Yii2 именно AR в коробке

Привет пипл

я тут на опен сервер короче и...

я тут на опен сервер короче и...

pdo extension не установлен на твоем опен сервере http://yiiframework.ru/forum/viewtopic.php?t=42094

дык это только на этом проекте что самое интересное