Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 177
Поздравляю. Долгожданный релиз!
Алилуя! Отличная новость
Ожидал релиза еще только 20-го числа, а тут на тебе!
Ура! Поздравляю авторов, всех без исключения. Наконец-то дождались релиза! Теперь осталось только подвинуть Laravel с занятых позиций.
Очень актуальный вопрос, кстати. Я только пару дней назад поставил Laravel, для тестов. А тут еще и Yii 2 вышел.
Ни тем, ни тем не пользовался. Выбор осложнился ((
Ни тем, ни тем не пользовался. Выбор осложнился ((
Пробуйте оба.
Попробуйте Symfony или RoR.
Почему «или»?
Не ради холивара. Глядя на ActiveRecord в Yii 2, понимаешь, какие они классные в RoR.
Не ради холивара было бы так: «Глядя на ActiveRecord в Yii 2 подумал что можно перенять вот эти идеи из RoR: X, Y, Z» ;)
Я один не понял ни вашего высказывания ни aTei?
ActiveRecord в php никогда не будет таким же клевым как в RoR, потому что PHP не Ruby и объектная модель у этих двух языков в корне отличается. Именно по этой причине в RoR их ActiveRecord можно эффективно использовать буквально для всего, а в Yii2 все наследуется от каких-то мегажирных классов, появляются кастыли с бихейверами и т.д.
ActiveRecord в php никогда не будет таким же клевым как в RoR, потому что PHP не Ruby и объектная модель у этих двух языков в корне отличается. Именно по этой причине в RoR их ActiveRecord можно эффективно использовать буквально для всего, а в Yii2 все наследуется от каких-то мегажирных классов, появляются кастыли с бихейверами и т.д.
Не, ну Eloquent довольно близко. Разве что belongs_to, before\after, scope и прочие задаются толстыми методами, а не парой строк, вида:
class Comment < ActiveRecord::Base
belongs_to :user
scope :older_than, -> timestamp { where 'created_at > ?', timestamp }
end
class Comment extends Eloquent
{
public function user() { return $this->belongsTo('User'); }
public function scopeOlderThan($query, $timestamp) { return $query->whereRaw('created_at > ?', [$timestamp]); }
}
Дак и AR в Yii тоже похож:
class Comment extends ActiveRecord
{
public function getUser()
{
return $this->hasOne(User::className(), ['id' => 'user_id']);
}
public static function find()
{
return new CommentQuery(get_called_class());
}
}
class CommentQuery extends ActiveQuery
{
public function olderThan($timestamp)
{
$this->andWhere('>', 'timestamp', $timestamp);
return $this;
}
}
Чем они классные?
Отлично! Больше добавить нечего +)
Ура товарищи вот он долгожданный релиз yii2, особенно понравилась новая версия работы интернационализации
Только, к сожалению, для удобной интернационализации в Yii сильно не хватает утилиты типа Poedit, как в WordPress.
Можно сделать…
Если я не ошибаюсь, в yii2 есть импорт-экспорт в .po, так что можно использовать тот же poedit вполне.
github.com/zelenin/yii2-i18n-module
такой модуль написал. Через веб-интерфейс переводим, есть экспорт/импорт.
такой модуль написал. Через веб-интерфейс переводим, есть экспорт/импорт.
Вот это хорошо, вышли из бетты в релиз достаточно быстро!
Хорошие новости с понедельника! Ура!
Ура, поздравляю!
Как раз новые проекты уже на 2й версии начали делать :)
Как раз новые проекты уже на 2й версии начали делать :)
Yii2 такой же торт, как и Yii1.1 в свое время.
Особенно радует поддержка эластика и сфинкса из коробки.
Особенно радует поддержка эластика и сфинкса из коробки.
Ура! Мир сегодня шагнул еще на одну ступень в развитии web фреймворков. Поздравляю всех!
Ну, поздравляю! Какие ваши дальнейшие действия по развитию? С кем планируете бороться и как?
Молодцы, спасибо вам огромное.
Ура!) Долгожданный релиз!
Молодцы, быстро прошли от беты до RC, а теперь релиз)
Не поторопились?;) все хорошо?;)
Молодцы, быстро прошли от беты до RC, а теперь релиз)
Не поторопились?;) все хорошо?;)
Рад за Вас. Постоянно использую Ваш фреймворк для фильтрации кандидатов на собеседование. Просто задаю вопрос — нравится. не нравиться, и сразу многое стает понятно.
Какой странный фильтр :)
Особенно если учесть что в первой версии хватало велосипедов которые вызывали раздражение при работе.
Просьба разъяснить что конкретно становится понятно конкретно обо мне, если я скажу, что я не люблю первый Yii и сторонник Laravel, RoR и Symfony? Так, мне просто любопытно. =)
З.Ы. Про второй Yii я ничего не говорил, т.к. мнения пока не сложилось.
З.Ы. Про второй Yii я ничего не говорил, т.к. мнения пока не сложилось.
Я думаю, что имела место просто пунктуационная ошибка. Так что полагаю именно «не люблю yii1» и хотел услышать автор сего комментария.
Просьба разъяснить что конкретно становится понятно конкретно обо мне, если я скажу, что я не люблю первый Yii и сторонник Laravel, RoR и Symfony? Так, мне просто любопытно.Вы испытываете острую потребность в прочной и глубокой привязанности, эмоциональном комфорте и защите от внешних воздействий. Потребность в понимании, любви и поддержке является ведущей и поэтому наиболее легко травмируемой мишенью. Вас характеризуют дружелюбие, конформность установок, но и замкнутость, избирательность в контактах, аналитический склад ума, вдумчивый подход к решению проблем, инертность в принятии решений, преобладание стремления к покою, уединенности. Всплески активности быстро сменяются фазой пассивности.
А я огорчился, что так быстро выпустили релиз! Мне настолько понравился Yii 2, что теперь придётся переписывать всё с Yii 1 (:
Ура!
Только в пятницу уговаривал клиента потерпеть и остаться на бете, поскольку «уже RC2 и релиз не за горами».
Прямо подарок )
Только в пятницу уговаривал клиента потерпеть и остаться на бете, поскольку «уже RC2 и релиз не за горами».
Прямо подарок )
Скажите, а есть для миграций авто-генерация того что в up и down. Натравил на таблицу и получил готовый результат, без ручного заполнения.
Нет. Технически реализовать можно, но штука получится опасная. Выстрелить из такой в ногу — раз плюнуть.
Вот отлично работает в доктрине, не надо в ногу стрелять.
А вот сейчас пишу на Laravel — там миграции один в один, так уже стреляют — писать руками людям влом, старое меняют.
А вот сейчас пишу на Laravel — там миграции один в один, так уже стреляют — писать руками людям влом, старое меняют.
Ну, старое менять — верный способ :) Попробую как-нибудь запилить ещё раз. Может выйдет лучше.
В доктрине у вас главные объекты и отношения между ними, вы полностью описываете мэппинг и сравнить что описано и то в базе проблемы не составляет. А в AR (покрайнемере в Yii) мэппинг ресолвится по таблицам, так что сделать diff не из чего… Так что соглашусь с SamDark, получится неплохая такая пушка для выстрелов в ногу, особенно учитывая любовь начинающих разработчиков не разбираться с тем что они используют.
Было бы неплохо иметь автогенерацию и down от нее. А применение этой миграции уже на совести прогера. Можно сделать так, чтобы код внутри ф-ии был закомментирован, и если программист его раскомментировал, значит он понимает и согласен с тем что сгенерировалось. А выстрелить в ногу можно и вручную, допустив ошибку в запросе.
Хорошо было бы всё-таки не запросами генерить а построителем.
У меня в моем ORM были активрекордс для баз, таблиц, пользователей и ключей. В реальности оно не так часто бывает нужно, и вполне можно обойтись и чуть другими методами, но довольно привычка пользоваться обычными гридами и т.п. для структуры базы осталась). Но сам я миграции как и все пишу копированием запросов в файлик. Иногда лезу в консоль и создаю пустую миграцию, иногда файлик копирую соседней миграции и переименовываю. Запрос беру из пхпмайадмина. Каждый раз говорю себе — не ленись, пиши на пхп а не sql, и потом каждый раз ругаю себя когда надо перейти на какой-то другой СУБД, но всё равно делаю на SQL — ибо лень)
У меня в моем ORM были активрекордс для баз, таблиц, пользователей и ключей. В реальности оно не так часто бывает нужно, и вполне можно обойтись и чуть другими методами, но довольно привычка пользоваться обычными гридами и т.п. для структуры базы осталась). Но сам я миграции как и все пишу копированием запросов в файлик. Иногда лезу в консоль и создаю пустую миграцию, иногда файлик копирую соседней миграции и переименовываю. Запрос беру из пхпмайадмина. Каждый раз говорю себе — не ленись, пиши на пхп а не sql, и потом каждый раз ругаю себя когда надо перейти на какой-то другой СУБД, но всё равно делаю на SQL — ибо лень)
Иметь возможность делать delete тоже опасная штука, ну как без него, когда надо. Было бы хорошо как предложили ниже: скажем создано, но закомментировано — а дальше можно просмотреть если что и подправить. Просто выходит создавать структуру в базе, а потом еще раз в миграциях — лишние телодвижения.
А зачем создавать структуру в базе, ведь можно один раз в миграциях. Заодно и проверите, что они работают.
Какой-нибудь dbForge, который все покажет, привычней.
Вы еще и под виндой… ух…
На самом деле используя API DBAL можно спокойно себе написать миграцию не связываясь с SQL. Хотя лучше через SQL. Миграции это не только «добавить поле в базу», это еще и наполнить эту базу или изменить структуру оной что бы ничего не поломалось.
Хотя в идеале у вас изменения в базе не должны влиять на предыдущий релиз, что бы можно было накатывать миграции до того, как переключить симлинки со старой на новую версию приложения. Хотя думаю этот вопрос вам вообще до лампочки.
На самом деле используя API DBAL можно спокойно себе написать миграцию не связываясь с SQL. Хотя лучше через SQL. Миграции это не только «добавить поле в базу», это еще и наполнить эту базу или изменить структуру оной что бы ничего не поломалось.
Хотя в идеале у вас изменения в базе не должны влиять на предыдущий релиз, что бы можно было накатывать миграции до того, как переключить симлинки со старой на новую версию приложения. Хотя думаю этот вопрос вам вообще до лампочки.
В базе привычно и удобно. Создал в базе, из нее в гии создал модельку, из базы же скопировал запросы создания структуры в миграцию, добавил пару строк для начального заполнения и готово. Прикольно было бы в гии модель делать указывая поля и их типы прямо в форме создания модели, и чтобы он из нее же добавлял миграцию. С внешними ключами, лейблами и гулящими женщинами. Примерно как в пхпмайадмин мы табличку создаем, только с выбором типов, связей и т.п. из пространства юии.
Я просто оставлю это здесь
Я предлагал включить этот функционал в ядро, но cebe отказал ) Сказал, что слишком опасно.
Я предлагал включить этот функционал в ядро, но cebe отказал ) Сказал, что слишком опасно.
Мало ли кто и как себе в ногу стреляет. Я например вообще люблю себе в ногу стрелять вот так:
И что теперь чтобы я себе в ногу не стрелял будут что-то в ядро добавлять?)))
ИМХО более чем достаточно добавить в начало создаваемых методов выброс исключения «Дорогой друг, проверь код миграции _ИМЯ_МИГРАЦИИ_ и удали эту строчку.»
/**
* Performs db migration to the latest available version
*/
public function actionMigrateUp()
{
try{
$commandPath = Yii::app()->getBasePath() . DIRECTORY_SEPARATOR . 'commands';
$runner = new CConsoleCommandRunner();
$runner->addCommands($commandPath);
$commandPath = Yii::getFrameworkPath() . DIRECTORY_SEPARATOR . 'cli' . DIRECTORY_SEPARATOR . 'commands';
$runner->addCommands($commandPath);
$args = array('yiic', 'migrate', '--interactive=0');
ob_start();
$runner->run($args);
echo nl2br(CHtml::encode(ob_get_clean()));
}catch(Exception $e){
echo $e->getMessage();
}
}
public function actionMigrateDown()
{
try{
$commandPath = Yii::app()->getBasePath() . DIRECTORY_SEPARATOR . 'commands';
$runner = new CConsoleCommandRunner();
$runner->addCommands($commandPath);
$commandPath = Yii::getFrameworkPath() . DIRECTORY_SEPARATOR . 'cli' . DIRECTORY_SEPARATOR . 'commands';
$runner->addCommands($commandPath);
$args = array('yiic', 'migrate', 'down', '--interactive=0');
ob_start();
$runner->run($args);
echo nl2br(CHtml::encode(ob_get_clean()));
}catch(Exception $e){
echo $e->getMessage();
}
}
И что теперь чтобы я себе в ногу не стрелял будут что-то в ядро добавлять?)))
ИМХО более чем достаточно добавить в начало создаваемых методов выброс исключения «Дорогой друг, проверь код миграции _ИМЯ_МИГРАЦИИ_ и удали эту строчку.»
Не знаю, не знаю. Мой гист спокойно проходит, как мне кажется, большую часть баз данных (хотя проверял на MySql только). Создает FK, PK индексы и прочие типы последовательно и используя абстракцию, предоставленную в классе Schema.
Сам гист я перерабатывал из существующего для Yii 1.1. имея знакомство с фреймворком только по мануалам, но не смотря на это он отработал на отлично, и я спокойно перенес базу созданную в MySQL Workbench в миграции.
Сам гист я перерабатывал из существующего для Yii 1.1. имея знакомство с фреймворком только по мануалам, но не смотря на это он отработал на отлично, и я спокойно перенес базу созданную в MySQL Workbench в миграции.
Ну для себя то конечно именно так и пишут. А когда пишут для других, то часто ставят предохранитель даже на револьверы :)
В принципе согласен, что человек который не перечитывает автогенеренный код, и не потрудившийся при этом обеспечить себя нормальным ревью выстрелит в ногу и более простым способом. Но паранойя говорит что в таком нежном месте лучше перестраховаться.
В принципе согласен, что человек который не перечитывает автогенеренный код, и не потрудившийся при этом обеспечить себя нормальным ревью выстрелит в ногу и более простым способом. Но паранойя говорит что в таком нежном месте лучше перестраховаться.
А в чем проблема параллельно подключить Propel и миграции на нем выполнять?
Жирноват он только для миграций.
Проще заменить им AR Yii или вообще на Doctrine. Но тогда от Yii мало чего останется.
Ушел на Symfony 2
Скажите, пожалуйста, есть ли полная поддержка Hip Hop compiler от Facebook?
Тесты проходят, но я не уверен на 100%, что оно заведётся.
Hip Hop compiler вроде как устаревшая уже давно технология. Нынче все крутится на HHVM, никаких компиляторов, только JIT.
На самом деле должно работать, просто попробуйте. Но велик риск что прирост производительности выполнения PHP кода вы убъете медленной и не оптимизированной базой.
На самом деле должно работать, просто попробуйте. Но велик риск что прирост производительности выполнения PHP кода вы убъете медленной и не оптимизированной базой.
Спасибо, мне ваш ответ стал полезным!
я использую hhvm в своих проектах уже с пол года, никаких проблем (wordpress, yii1, yii2 alpha, vbulletin, bitrix). Прирост производительности есть, но не могу сказать что прям большая разница. Но ресурсов потребляет явно меньше (на wordpress раза в 2). Теперь жду php-ng, хочу потестировать и его.
Единственное с чем у меня возникла проблема при использовании hhvm так это с кэшированием при использовании плагинов для wordpress в memcache, в итоге поставил w3 total cache, кэш в файлы и теперь всё ок. Поэтому нужно обязательно в проектах всё оборачивать в тесты, тогда сразу будет понятно есть ли проблемы.
Единственное с чем у меня возникла проблема при использовании hhvm так это с кэшированием при использовании плагинов для wordpress в memcache, в итоге поставил w3 total cache, кэш в файлы и теперь всё ок. Поэтому нужно обязательно в проектах всё оборачивать в тесты, тогда сразу будет понятно есть ли проблемы.
Я про HHVM отвечал, если что…
Скажите нет ли в планах добавить в стандартную поставку, компоненты для работы с деревьями: nested sets, adjacency list…
В стандартную нет. Качественное расширение для nested set стоит ждать от creocoder. По adjacency list он тоже что-то думал реализовывать.
Судя по всему уже готово, github.com/creocoder/yii2-nested-set-behavior
Себе тоже забрал.
Себе тоже забрал.
было готово для pre-alpha или alpha, но потом перестало работать. Creocoder обещал адаптировать с выходом релиза.
Как все печально… Ни тебе DRY, ни тестов… Интересно что будет если прогнать через phpmd или еще лучше через scrutinizer-ci.
Умгу. Это для альфы делалось с целью прикинуть, достаточно ли гибок AR. Для 1.1 тесты и всё остальное есть, думаю и в релизе будут.
Поздравляю. Печалит только одно, теперь придется изучать, а лень :)
Получилась ли наконец-то поддержка шардинга в ORM и шардированных миграций?
Нет. Шардинг — штука специфичная и его стратегия сильно меняется от проекта к проекту. Зато появилась поддержка read/write split-а и репликации.
Печально. Именно из-за отсутствия не только шардинга из коробки, но и подходящего слоя абстракций для его реализации, пришлось в двух проектах отказываться от Yii.
Напишите мне в почту, обсудим. Я пока слабо представляю, как можно из шардинга сделать что-то стандартное, покрывающее все случаи.
Может вы бы лучше здесь обсудили? Думаю не только мне было бы интересно.
Шардинг в юии мне видится как переопределение компоненты дб своей прослойкой которая уже будет по своей логике разруливать между базами. По идее все модели должны обращаться к дб, хардкод запросов и т.п. тоже должен идти через нее, так что если нигде костылей нет, то по хорошему тут хватит и абстрактного класса который будет содержать в себе все коннекты к разным базам и различную типовую логику. Но это чисто теоретически. На юии я до шардинга ни разу не доходил…
Шардинг в юии мне видится как переопределение компоненты дб своей прослойкой которая уже будет по своей логике разруливать между базами. По идее все модели должны обращаться к дб, хардкод запросов и т.п. тоже должен идти через нее, так что если нигде костылей нет, то по хорошему тут хватит и абстрактного класса который будет содержать в себе все коннекты к разным базам и различную типовую логику. Но это чисто теоретически. На юии я до шардинга ни разу не доходил…
Мы делали шардинг на Yii 1.1. CActiveRecord почти идеально подходит для этого, нужен только один костылик для подмены имени таблицы в getMetaData()->tableSchema->rawName. Я обращался с этим вопросом к SamDark, но он посчитал его «немного странным», ибо «MySQL легко работает с сотнями миллионов записей, если дать ему достаточно памяти» ;) (пруфлинк). В остальном в сущности достаточно переопределить методы tableName и getDbConnection, написать маппер для определения бд и таблицы, а так же позаботиться о том, чтобы атрибут для определения шарда присутствовал в модели при создании выборок. Плюс мы ещё делали простой итератор для выборок из всех шардов (для статистических запросов в основном) и общий автоинкремент. Могу выложить куда-нибудь, если интересно.
В Yii2 методы tableName и getDbConnection стали статичными, что осложняет использование шардинга в ActiveRecord. Но в реальности в сложных нагруженных проектах есть смысл отказаться от ActiveRecord вообще и использовать более лёгкие конструкции для работы с данными с целью повышения производительности.
PS: Хак для переопределения имени таблицы в CActiveRecord:
В Yii2 методы tableName и getDbConnection стали статичными, что осложняет использование шардинга в ActiveRecord. Но в реальности в сложных нагруженных проектах есть смысл отказаться от ActiveRecord вообще и использовать более лёгкие конструкции для работы с данными с целью повышения производительности.
PS: Хак для переопределения имени таблицы в CActiveRecord:
public function getMetaData()
{
$md = parent::getMetaData();
$md->tableSchema->rawName = $this->getDbConnection()->quoteTableName($this->tableName());
return $md;
}
В Yii2 методы tableName и getDbConnection стали статичными, что осложняет использование шардинга в ActiveRecord.
Благодарю, полезная информация. У меня сейчас как раз один проект в котором живет два фреймворка, один из которых юии1.1 подрос до глобального рефакторинга. Нагрузка пока в пределах, но это важный фактор для принятия решения. Думаю куда двигаться — переносить обе части на юии2, или переносить депрекейтед-фреймворк на юии1.1, и пока не заморачиваться. Всё больше склоняюсь к тому, что технология которую все знают (юии1) будет разумнее на данном этапе. И похоже Ваш аргумент будет решающим :)
Могу выложить куда-нибудь, если интересно.
Был бы премного благодарен.
Выложил на github. В примере реализация с фиксированным количеством шардов, но можно сделать и создание нового шарда на каждые N новых ключей, используя тот же интерфейс.
На мой взгляд, все сложнее. Как только возникла необходимость реализации связей вообще ленивого поиска в частности оказалось, что нужно переопределять кучу внутренних классов — причем во многих случаев они не были рассчитаны на наследование и переопределение. После некоторого времени борьбы стало понятно, что тратится больше времени на попытки совместить свои дочерние классы с ядром Yii, чем экономится от его использования, и пришлось отказаться.
Да, примерно так все и устроено, но, как я упоминал в другой ветке, нужно, чтобы смежные классы — особенно отвечающие за работу связей, предусматривали такую возможность.
Для шардинга необходимо, чтобы к моменту вызова getDbConnection() у класса было уже достаточно данных для обращения к нужному споту данных. В старом Yii под капотом (особенно в случае с построением дерева Join) нередко вызывалась в непредсказуемом снаружи месте конструкция ModelName::model(), что приводило к работе с пустыми полями и невозможности установить корректное соединение. Также было невозможно задать свои реализации ActiveFinder, например. Вернее, для того, чтобы их использовать, приходилось переопределять и все те места, где они вызываются я ядре, так как абстракции не были заложены.
Все эти проблемы, теоретически, подлежали решению, но на каком-то этапе оно стала требовать неадекватно больших усилий.
Для шардинга необходимо, чтобы к моменту вызова getDbConnection() у класса было уже достаточно данных для обращения к нужному споту данных. В старом Yii под капотом (особенно в случае с построением дерева Join) нередко вызывалась в непредсказуемом снаружи месте конструкция ModelName::model(), что приводило к работе с пустыми полями и невозможности установить корректное соединение. Также было невозможно задать свои реализации ActiveFinder, например. Вернее, для того, чтобы их использовать, приходилось переопределять и все те места, где они вызываются я ядре, так как абстракции не были заложены.
Все эти проблемы, теоретически, подлежали решению, но на каком-то этапе оно стала требовать неадекватно больших усилий.
Уберите join-ы — и жизнь сразу станет легче ;). В сложных проектах гораздо более гибкой и долгоиграющей стратегией будет реализация связей на уровне приложения, а не базы данных. Естественно, появится небольшой оверхед на дополнительные запросы, но будет и профит в виде возможности более гибко и эффективно масштабироваться.
Совершенно верно, но это не значит, что связи не должны быть прописаны. Если мы пытаемся сохранить подход ActiveRecord, то он должен поддерживать и установку связей под капотом.
А воплощаются ли они в реальную sql-команду join или объелиняются в приложении — вопрос реализации, которая под капотом и останется (в идеале). В случае с шардированными записями это наверняка будет сделано именно в приложении.
А воплощаются ли они в реальную sql-команду join или объелиняются в приложении — вопрос реализации, которая под капотом и останется (в идеале). В случае с шардированными записями это наверняка будет сделано именно в приложении.
Не плохая стратегия, но противоречит патерну «обрабатывать данные там где они храняться». Тогда уж лучше оверхедить, создавая нормальные представления и логику связей по ключам.
Паттерн «информационный эксперт» несколько не о том гласит. Он гласит «обрабатывать данные там где они есть», но это только в контексте ООП, иначе по этой логике большая часть бизнес логики у нас перенеслась бы в хранимые процедуры. А вот реализовать построение запросов при join и гидрации так, что бы клиентский код не заподозрил бы что джойнов то и небыло и все было получено и склеено внутр ORM это нормально.
Чем вам php не ОО? Так вы оставляйте бизнес логику в обрабатывающем данные коде, а вот контроль и преобразование можно уже разносить между ORM и процедурами. DiZeee прав в плане «избегать join-ы» (скорость решает, тк неоднократно вспомнили здесь, что БД — самое узкое место). Любой join можно заменить на представление и это будет быстрее.
Использую join-ы, как индикатор проблемных мест: нашёл, переписал, производительность повысил)) Единственный момент где понадобится без вариантов join — это динамические линковки, но в реальной жизни такое не попадалось.
И, в конце-то концов, всё можно написать на pgsql!
Использую join-ы, как индикатор проблемных мест: нашёл, переписал, производительность повысил)) Единственный момент где понадобится без вариантов join — это динамические линковки, но в реальной жизни такое не попадалось.
И, в конце-то концов, всё можно написать на pgsql!
Причем тут php и ОО? Я про «информационного эксперта» вне контекста ООП. По поводу отказа от джойнов, вьюшек и т.д. я полностью согласен. И по поводу pgsql так же. Я больше к тому что паттерны все эти и другие GRASP-овские принципы они не о том. Тут вопрос конкретно в архитектуре базы данных. Вьюшки, процедуры, словом сокрытие сложности реализации архитектуры на уровне базы данных вместо DBAL/ORM вполне себе логичны. Просто некоторые стараются избегать этого всего так как «усложняется деплоймент». Главное что бы наши доменные модели не знали как их кто хранит и выбирает.
разьве нельзя стратегию вынести в интерфейсы? В doctrine уже делались какие-то безуспешные попытки работы с кластером.
Поддержка репликации это то-же самое что поддержка r/w/x, разьве нет? Просто внесли доп.слой абстракции в конфиги и quiery-builder? Это все полезно, но — неинтересно. Интересен шардинг на уровне подключения, БД, таблиц, мигратора.
Что-то в этом направлении будет делаться к релизу Yii3 еще лет через пять?
Поддержка репликации это то-же самое что поддержка r/w/x, разьве нет? Просто внесли доп.слой абстракции в конфиги и quiery-builder? Это все полезно, но — неинтересно. Интересен шардинг на уровне подключения, БД, таблиц, мигратора.
Что-то в этом направлении будет делаться к релизу Yii3 еще лет через пять?
Как вы уже и сказали, в доктрине была попытка сделать экстеншен для DBAL для упрощения шардинга… но как-то все зачахло. Проблемы которые нужно решить хорошо расписаны в документации. И вы серьезно думаете что это должно хоть как-то решаться на уровне ORM? Мне казалось что проекты которые оперируют такими объемами данных что приходится к шардингу прибегать стараются избегать использования ORM, или как минимум там не подходит ActiveRecord.
Да я бы не сказал. ActiveRecord — это только интерфейс, сам по себе он не создает страшного оверхеда, а плюсы в большом проекте те же, что и в малом — простота реализации бизнес-логики, которая (простота) может быть для большого проекта, где сложностей и так хватает, критичнее докупки нескольких серверов, если таковая вообще понадобится. В любом проекте есть слой абстракции над БД, такой или другой, совсем без оверхеда не обойтись.
Мне случалось организовывать шардинг на ActiveRecord для нагруженного проекта, вполне приемлемо. Да, некоторые ограничения есть — в основном, с группировкой и сортировкой, и их приходится учитывать при использовании, но от этого никуда не деться, а плюсы, с моей точки зрения, того стоят.
Мне случалось организовывать шардинг на ActiveRecord для нагруженного проекта, вполне приемлемо. Да, некоторые ограничения есть — в основном, с группировкой и сортировкой, и их приходится учитывать при использовании, но от этого никуда не деться, а плюсы, с моей точки зрения, того стоят.
Как раз каноническая ActiveRecord, с её подходом «таблица<->класс, запись<->объект», подходит нормально, требуя лишь небольших изменений «однонодового» кода. Проблемы начинаются при попытках нагрузить ORM групповыми задачами с агрегациями и сортировками, для которых ActiveRecord не предназначен — его задача-максимум выбрать список объектов по условию без гарантированного порядка, предполагая агрегацию и сортировку на стороне приложения.
Володь, как Вы себе представляете сортировку на стороне приложения в банальной пагинации? Если есть лимит, то сортировка неизбежно на стороне базы.
Это уже не проблема конкретно подхода ActiveRecord — с такими сложностями вы столкнетесь в любом случае, делая пагинацию по шардированным записям с условиями выборки, группировки, сортировки, какой бы ни была прослойка для работы с базой.
Сильно зависит от задачи. Сферический пример — форум. Шардинг таблицы комментариев. Разносим по нодам по полю топикИд. Условие запроса топикИд=ххх, сортировка по дате, ну или по ид, как «неявному времени» для уменьшения ключей. Я понимаю что пример сферический, и к примеру поиск, или поиск всех сообщений пользователя всё поломает, но задачи бывают разные…
Я писал: с такими сложностями вы столкнетесь в любом случае, делая пагинацию по шардированным записям с условиями выборки, группировки, сортировки
В приведенном вами случае это как раз поиск по нешардированным записям, если они у вас все в одной базе. Независимо от того, что где-то в проекте есть подобные таблицы, относящиеся к другим спотам, конкретно этот запрос будет работать с плоской структурой данных.
В приведенном вами случае это как раз поиск по нешардированным записям, если они у вас все в одной базе. Независимо от того, что где-то в проекте есть подобные таблицы, относящиеся к другим спотам, конкретно этот запрос будет работать с плоской структурой данных.
почему не шардированная? в рамках запроса плоская, но таблица то шардированная.
Мне кажется, вы меня не понимаете.
У вас есть 4 грузовика (шарда) с яблоками (данными). В каждой сидит грузчик (СУБД), готовый по запросу эти яблоки отдавать.
Я утверждаю, что проблема поиска, например, 20-и самых красных яблок по всем машинам и выкладывания их по убыванию красноты, независимо ни от сноровки грузчика (организации базы), ни от того, как точно вы сформулируете ему задачу (архитектура прослойки), не может быть решена без взаимодействия или грузчиков между собой или каждого из них с вами (приложением).
Вы говорите: может, если искать только в одном грузовике. Я отвечаю: да, но это не имеет отношения к задаче поиска по нескольким машинам. Вы говорите: как не имеет, вот же они рядом стоят. А за углом еще две. А еще у меня груши есть…
У вас есть 4 грузовика (шарда) с яблоками (данными). В каждой сидит грузчик (СУБД), готовый по запросу эти яблоки отдавать.
Я утверждаю, что проблема поиска, например, 20-и самых красных яблок по всем машинам и выкладывания их по убыванию красноты, независимо ни от сноровки грузчика (организации базы), ни от того, как точно вы сформулируете ему задачу (архитектура прослойки), не может быть решена без взаимодействия или грузчиков между собой или каждого из них с вами (приложением).
Вы говорите: может, если искать только в одном грузовике. Я отвечаю: да, но это не имеет отношения к задаче поиска по нескольким машинам. Вы говорите: как не имеет, вот же они рядом стоят. А за углом еще две. А еще у меня груши есть…
Мы с Вами немного о разных вещах. Я говорю о том, что во многих ситуациях можно обойтись без решения проблемы сортировки и группировки в шардах, если таковая будет использоваться на стороне ноды, а не на стороне приложения. Вы говорите о том, что бывают случаи когда это невозможно. Ну да, бывают :) Я же не спорю то. Скорее всего они и будут в реальном проекте. Но зачем себе усложнять жизнь? В начале ветки спор начался с того можно ли отказываться от сортировки на стороне СУБД.
Если есть лимит, то это уже слабо относится к ActiveRecord, да и вообще ORM. Это область ответственности всяких QueryBuilder и Repository, которые используют ORM в качестве маппера.
А теперь долгая и нудная миграция проекта с 1.1 на 2.0 =\
Всем привет
Хочу в будущем php изучить. Какой фреймворки лучше изучать после основ php?
Пока я на jquery еще, но потом после пойду в наступление на php
Хочу в будущем php изучить. Какой фреймворки лучше изучать после основ php?
Пока я на jquery еще, но потом после пойду в наступление на php
Yii и начинай, хорошая штука ;)
Спасибо за совет.
В вакансиях чаще вижу или Zend Framework, или все 3 фреймворка вместе. Сам пока не разбираюсь, поэтому и прошу совета профессионалов :)
В вакансиях чаще вижу или Zend Framework, или все 3 фреймворка вместе. Сам пока не разбираюсь, поэтому и прошу совета профессионалов :)
Работаю на фреймворках много и давно, в рунете Yii хотят в большинстве проектов. Начинал использовать фреймворки с ZF и сейчас на нем найти работу гораздо сложнее, чем на Yii.
Yii и проще для старта. Я бы тоже с него рекомендовал начать.
Yii и проще для старта. Я бы тоже с него рекомендовал начать.
Говорю именно по личному опыту не претендуя на холивар. Года два назад тоже решил изучить какой-нибудь фреймворк — выбор пал на Yii, довольно много провозился и в итоге разочаровался, не только из-за проблем в освоении (может я просто краб), но в основном просто из-за обилия бессмысленных конфигов и отсутствия модульности, перешёл на Laravel — никаких нареканий или вопросов ко второму не было — изучился сходу, как по маслу. Так что тут каждому своё.
Но всё же в ру-регионах более востребованный Yii, так что думаю всё же стоит взяться за Yii (хотя в европейских странах и америке — ларавелька уже давно всех обогнала по уровню популярности). Всё зависит от цели — зачем именно изучать.
Но всё же в ру-регионах более востребованный Yii, так что думаю всё же стоит взяться за Yii (хотя в европейских странах и америке — ларавелька уже давно всех обогнала по уровню популярности). Всё зависит от цели — зачем именно изучать.
Я верно понимаю, что Yii был вашим первым фреймворком? Если да, то дело в том, что второй фреймворк учится всегда легче.
Скорее вторым, т.к. первый был немного переработанный Zend (уже готовый проект на поддержке), но не совсем в том виде, под которым подразумевают «изучить», скорее «знаю как работает, где-что вызывается и что-где создавать и писать», без изучения ядра и всяких специфических возможностей, так что можно считать Yii моим «полторашным» фреймворком.
В любом случае — я совершенно солидарен, всё учится проще, если это второе или третье «решение», будь то фреймворк или язык программирования, и вполне может быть в этом и есть причина, почему судьба сложилась именно так.
В любом случае — я совершенно солидарен, всё учится проще, если это второе или третье «решение», будь то фреймворк или язык программирования, и вполне может быть в этом и есть причина, почему судьба сложилась именно так.
Но положа руку на сердце и без всяких уже сложившихся стереотипов — доки у Laravel всё же мне больше импонируют.
Допустим я опять решил изучить Yii — хочу найти роутинг — захожу на Yii и открываю документацию, вот что я нахожу: www.yiiframework.com/doc-2.0/guide-runtime-routing.html а вот, что я вижу у Laravel: laravel.com/docs/4.2/routing
UPD: Если я ошибся ссылкой на доки по Yii — прошу меня простить и поправить.
Допустим я опять решил изучить Yii — хочу найти роутинг — захожу на Yii и открываю документацию, вот что я нахожу: www.yiiframework.com/doc-2.0/guide-runtime-routing.html а вот, что я вижу у Laravel: laravel.com/docs/4.2/routing
UPD: Если я ошибся ссылкой на доки по Yii — прошу меня простить и поправить.
Да, немного промахнулись: www.yiiframework.com/doc-2.0/guide-runtime-url-handling.html
Очень интересен опыт сравнения Yii и Lavarel.
Правильно ли я понимаю, что вы работали с первой версией Yii? Или удалось пощупать и вторую версию?
Laravel, думаю, не зря так резво набирает популярность. Интересно ваше мнение — почему?
Анализировал фреймворки для миграции с Zend'а (работал с ним с версии 0.7 и вторая версия откровенно разочаровала). Меня в Lavarel'e оттолкнула некоторая его «винигретность» — по ощущениям, надергано компонент из фреймворков и создается ощущение, что нет целостности и это все не способно работать идеально.
Yii 2 же после Zend'а мне кажется просто песней (не потому, что Zend был плох, а потому, что он скорее был основой для разработки своего фреймворка — все, что нужно надо было писать самому, а он только предоставлял инструменты). Часто слышу похожие сравнения Lavarel с Yii (типа «Yii хорош, и вы будете любить его пока не попробуете Laravel»). Что, несомненно, интригует.
Если есть реальный опыт разработки на обоих этих фреймворках — расскажите, в чем преимущества?
Правильно ли я понимаю, что вы работали с первой версией Yii? Или удалось пощупать и вторую версию?
Laravel, думаю, не зря так резво набирает популярность. Интересно ваше мнение — почему?
Анализировал фреймворки для миграции с Zend'а (работал с ним с версии 0.7 и вторая версия откровенно разочаровала). Меня в Lavarel'e оттолкнула некоторая его «винигретность» — по ощущениям, надергано компонент из фреймворков и создается ощущение, что нет целостности и это все не способно работать идеально.
Yii 2 же после Zend'а мне кажется просто песней (не потому, что Zend был плох, а потому, что он скорее был основой для разработки своего фреймворка — все, что нужно надо было писать самому, а он только предоставлял инструменты). Часто слышу похожие сравнения Lavarel с Yii (типа «Yii хорош, и вы будете любить его пока не попробуете Laravel»). Что, несомненно, интригует.
Если есть реальный опыт разработки на обоих этих фреймворках — расскажите, в чем преимущества?
Есть опыт разработки на Yii 1.4 и на Laravel 4, не скажу что Laravel идеален, но по сравнению с Yii, это просто сказка.
Актив рекорд и запросы связей с условием вызывает боль и страдание, если вы не понимаете про что я, то рекомендую прочитать yiiweb.wordpress.com/activerecord/relations/
Роутинг в Yii через пару месяцев превращается в сложно понимаемую кашу, из массивов. ( К сожалению, в версии 2, роутинг почти не изменился.)
Конфигурация виджетов через массивы, приносит очень много неудобств, и заставляет постоянно держать открытыми вкладки с документациями.
Но тут нужно сказать, что в Yii есть тот функционал которого нет в Laravel из коробки, и это иной раз подкупает.
Актив рекорд и запросы связей с условием вызывает боль и страдание, если вы не понимаете про что я, то рекомендую прочитать yiiweb.wordpress.com/activerecord/relations/
Роутинг в Yii через пару месяцев превращается в сложно понимаемую кашу, из массивов. ( К сожалению, в версии 2, роутинг почти не изменился.)
Конфигурация виджетов через массивы, приносит очень много неудобств, и заставляет постоянно держать открытыми вкладки с документациями.
Но тут нужно сказать, что в Yii есть тот функционал которого нет в Laravel из коробки, и это иной раз подкупает.
Правильное слово «из коробки». Этот отсутствующий функционал в Laravel легко дополняется пакетами, начиная с валидации в моделях, заканчивая всякими виджетами.
В 2.0 AR стал сильно лучше. Роуты можно группировать, вытаскивать в модули, строить на лету или реализовывать классами.
Не соглашусь по поводу роутинга в Yii. В первых моих проектах он действительно превращался в кашу, но потом я научился с ним обходиться. А если роутинг в приложении действительно очень сложен, то стоит посмотреть в сторону расширения роутинга своим классом.
Вы правильно сказали про винигретность! Именно такие ощущения о Laravel у меня и сложились. Кроме того, у Laravel внутри все как-то сложнее устроено и труднее понять что и как работает. Иногда сбоит автодополнение в IDE, а новомодные паттерны усложняют отладку (иногда сложно докопаться до реально именно того метода того класса, который вызывается), еще неприятно отсутствие встроенной в AR валидации. С другой стороны, у Laravel очень крутой artisan, более удобные конфиги и еще мелочи, которые мне сейчас трудно вспомнить.
Еще, как мне показалось, Yii проще в изучении и комьюнити у него приятнее.
Чисто субъективно, Laravel немного лучше, чем Yii, но хуже, чем Yii 2.
Еще, как мне показалось, Yii проще в изучении и комьюнити у него приятнее.
Чисто субъективно, Laravel немного лучше, чем Yii, но хуже, чем Yii 2.
Автодополнение легко восстанавливается одним пакетом «barryvdh/laravel-ide-helper», валидация в моделях, если очень надо — точно так же, пакетом ставится. Внутреннее устройство становится кристально очевидным после просмотра файлов запска приложения и самого класса Illuminate\Foundation\Application.
В остальном верно — у L4 очень много магии (имхо, даже с избытком), которая реализуется разработчиком буквально парой строчек, а осмысливается «что именно произошло и как оно работает» — довольно долго.
В остальном верно — у L4 очень много магии (имхо, даже с избытком), которая реализуется разработчиком буквально парой строчек, а осмысливается «что именно произошло и как оно работает» — довольно долго.
а новомодные паттерны усложняют отладку
этим паттернам уже лет 15. Или вы хотите сказать что поставив во главу угла можно сделать что-то хорошее? Что вообще вы под «винигретностью» подразумеваете? Для меня это сильно связанная система, в которой все перемешано.
неприятно отсутствие встроенной в AR валидации.
Так это же хорошо! AR ничего о валидации знать не должна.
поставив наследование во главу угла*
Для меня это сильно связанная система, в которой все перемешано.
Для меня это просто ощущение отсутствия целостности, единого подхода к разработке всех частей фреймворка. В принципе, ничего удивительного в том, что именно такое впечатление о Laravel у меня сложилось, так как по большей части он состоит из библиотек, взятых у других проектов.
Так это же хорошо! AR ничего о валидации знать не должна.
Писать каждый раз валидацию в контроллерах — странно, а выносить валидацию в отдельный класс — муторно и бессмысленно. Я еще ни разу не имел проблем из-за того, что у меня валидация была в AR.
AR ничего о валидации знать не должна
Смотря что считать валидацией. Валидация форм и параметров запросов — это одна валидация, проверка вызова сеттеров модели и других методов, изменяющих состояние, на то, что состояние будет соответствовать бизнес-модели — это другая валидация (на уровне форм зачастую нерешаемая без обращений к конкретным объектам модели). Но на практике, обычно, подавляющее большинство правил валидации форм и параметров сеттеров совпадают, а из модели их выносить нельзя, поскольку модели не только из форм заполняются. Потому хорошим решением выглядит или инкапсуляция всей валидации в модель, или (обычно красивее) вынос большей части валидации в сущность, от которой класс модели зависит. Альтернатива — дублирование кода.
1) Пощупал первую версию, не долго, с месяцок — запилил себе бложик, на этом закончил общение.
2) L4 набирает популярность из-за (имхо): Очень интересной идеологии (фасады + провайдеры), великолепной документации и компонентной базе, которая включает пакеты из других фреймворков — это позволяет развиваться ему на порядок быстрее любого фреймворка и в тоже время быть стабильнее (пока Yii 1 переходил на Yii 2 вышли версии L4, 4.1, 4.2 и в этом месяце выходит версия 5). Но основное преимущество именно в том, что разработчики брали всё самое лучшее от веб-среды, включая RoR и ASP.NET, а не изобретали своих велосипедов. Плюс 4-ка появилась во время «бума» Композера, что позволило буквально за год-два выйти в топ.
3) В 4ой версии такого ощущения нет — возникает внутреннее чувство сбалансированного автомобиля — всё на своих местах, работает как надо, ничего лишнего, а всё, что претендует на лишнее — вынесено из ядра. Например в Yii меня, как некого ценителя красоты — очень сильно раздражает наличие JS и вообще зависимости от JS внутри ядра. А вот про 5ку я уже такого не скажу, может она и мощнее, но лично у меня складывается впечатление некоторой «потерянной идеологии», всё вперемешку и как раз так, как Вы выразились — винегрет.
4) На Yii бложик (для себя, чтоб понять что за зверь такой), на L4 довольно много ресурсов, начиная от OAuth сервера, заканчивая всякими файлопомойками и некоторыми более серьёзными ресурсами. На счёт каких-то преимуществ рассказывать не стану, ибо считаю, что не совсем хорошо знаю и помню Yii, чтоб грамотно всё расписать не вдаваясь в холивары.
2) L4 набирает популярность из-за (имхо): Очень интересной идеологии (фасады + провайдеры), великолепной документации и компонентной базе, которая включает пакеты из других фреймворков — это позволяет развиваться ему на порядок быстрее любого фреймворка и в тоже время быть стабильнее (пока Yii 1 переходил на Yii 2 вышли версии L4, 4.1, 4.2 и в этом месяце выходит версия 5). Но основное преимущество именно в том, что разработчики брали всё самое лучшее от веб-среды, включая RoR и ASP.NET, а не изобретали своих велосипедов. Плюс 4-ка появилась во время «бума» Композера, что позволило буквально за год-два выйти в топ.
3) В 4ой версии такого ощущения нет — возникает внутреннее чувство сбалансированного автомобиля — всё на своих местах, работает как надо, ничего лишнего, а всё, что претендует на лишнее — вынесено из ядра. Например в Yii меня, как некого ценителя красоты — очень сильно раздражает наличие JS и вообще зависимости от JS внутри ядра. А вот про 5ку я уже такого не скажу, может она и мощнее, но лично у меня складывается впечатление некоторой «потерянной идеологии», всё вперемешку и как раз так, как Вы выразились — винегрет.
4) На Yii бложик (для себя, чтоб понять что за зверь такой), на L4 довольно много ресурсов, начиная от OAuth сервера, заканчивая всякими файлопомойками и некоторыми более серьёзными ресурсами. На счёт каких-то преимуществ рассказывать не стану, ибо считаю, что не совсем хорошо знаю и помню Yii, чтоб грамотно всё расписать не вдаваясь в холивары.
Спасибо всем за развернутые комментарии.
Решил, что Laravel буду тоже щупать. Вообще, чем больше фреймворков использовать, тем лучше — при взгляде с разных сторон более объективная картина складывается.
Решил, что Laravel буду тоже щупать. Вообще, чем больше фреймворков использовать, тем лучше — при взгляде с разных сторон более объективная картина складывается.
Все наши проекты уже давно мигрировали на Yii, и за 2 года очень довольны фреймворком.
А какие еще фреймворки, которые повыходили последние года 3 вы пробовали?
Я, например, пробовал Yii 1.1, Symfony, ZF2, Phalcon, CI. Ближе всех ментально оказался всё-таки наш отечественный, православный Yii. Сейчас потихоньку пробую Yii2, к сожалению старые проекты перенести будет проблематично из-за постоянно сжатых спринтов где нет времени на нормальный рефакторинг всей бизнес логики.
Кстатие Phalcon мне тоже понравился, интересная вещь, но когда я его осваивал в одном маленьком проекте у него было достаточно много проблем со стабильностью, хотя я слышал их устранили и он стал вполне стабилен для продакшена.
Кстатие Phalcon мне тоже понравился, интересная вещь, но когда я его осваивал в одном маленьком проекте у него было достаточно много проблем со стабильностью, хотя я слышал их устранили и он стал вполне стабилен для продакшена.
то чувство когда Yii1 еще не достаточно изучил, а уже вышел Yii2
С urlManager что-то перемудрили.
Почему что бы установить свои url rules, надо устанавливать enablePrettyUrl равным true?
Почему что бы установить свои url rules, надо устанавливать enablePrettyUrl равным true?
Потому что в обратном случае и свои и не свои rules игнорируются и все параметры представляются в виде
http://example.com/index.php?r=controller/action¶m1=value1¶m2=value2Не понятно, зачем игнорируются.
Получается невозможно добавить свои url rules и иметь их в виде:
Получается невозможно добавить свои url rules и иметь их в виде:
http://example.com/index.php?r=controller/action¶m1=value1¶m2=value2Хм… а как именно вы пытаетесь добавить rules?
Как обычно в конфиге config/web.php
'urlManager' => [
'enablePrettyUrl' => false,
'rules' => [
'zzz' => 'site/index',
],
],
Ничто не запрещает таким образом объявить правила. В чём проблема?
Запрещает: github.com/yiisoft/yii2/blob/master/framework/web/UrlManager.php#L61
Проверка enablePrettyUrl стоит в init() и addRules().
Похоже что rules игнорируются если enablePrettyUrl=false.
Проверка enablePrettyUrl стоит в init() и addRules().
Похоже что rules игнорируются если enablePrettyUrl=false.
Игнорируются, да. Потому что при отключенном
enablePrettyUrl их просто незачем использовать, ведь формат получается всегда стандартный. Но никакие исключения не кидаются, так что в коде можно смело прописывать и при включении enablePrettyUrl всё начнём добавляться и работать.Но получается свой урл к экшену нельзя написать: habrahabr.ru/post/240149/#comment_8072599
Если я не хочу иметь PrettyUrl.
В Yii1 это было возможно, а теперь странное ограничение ввели.
Если я не хочу иметь PrettyUrl.
В Yii1 это было возможно, а теперь странное ограничение ввели.
Ничего не понимаю. Что вы хотите получить при наличии правила
?
'zzz' => 'site/index', и выполнении кода:echo Url::to(['site/index']);
?
ну zzz
Я хочу чтобы но адресу
index.php?r=zzz
открывался site/index к примеру.
Я хочу чтобы но адресу
index.php?r=zzz
открывался site/index к примеру.
Не, так не работает. Получите
index.php?r=site/index. Если не секрет, для чего вам index.php?r=zzz и что мешает нормально настроить рерайт?
Насколько я понял во второй версии в любом вызове createObject() используется встроенный DI Container с обращением к рефлексии — это не вредит производительности? У первой версии фреймворка одно из главных преимуществ было в производительности, в том числе за счет отсутствия таких модных, но тяжелых решений.
Да, и кстати почему DI Container, а не общепринятое IoC Container?
Да, и кстати почему DI Container, а не общепринятое IoC Container?
Я все никак в толк не возьму. Почему в Advanced Application Template используется миграция с int типом для created_at и updated_at вместо timestamp. Может я еще не познал дзен?
Почему для реализации функционала timestamp используется TimestampBehavior, а не поведение бд?
Почему для реализации функционала timestamp используется TimestampBehavior, а не поведение бд?
В статье есть упоминание о генераторе документации, который поддерживает и бла-бла-бла… заинтересовали, заинтриговали, но ссылка уже битая… Куда копать? Где искать и как использовать?
Кстати, с основной страницы документации на github -тоже ссылка битая.
Может кто-то подскажет варианты? Или кто что использует для своих проектов на Yii2?
Кстати, с основной страницы документации на github -тоже ссылка битая.
Может кто-то подскажет варианты? Или кто что использует для своих проектов на Yii2?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yii 2.0. Релиз