Залез еще раз в код, посмотреть поточнее.
Метод называется insert. Внутри него после удачного собственно инсерта и проставления праймари ключа в модели вызывается вот что
А так да, afterSave вызывается и для insert, и для update. Но, мне кажется, можно параметром передавать вызываем мы его после добавления записи или обновления.
Да и потом где гарантии что вы уже создали все связанные объекты?
Это да, но проблема скорее архитектуры. Если я связные записи еще не сохранил, то и так вернется null записей.
Но в целом да, я уже пораскинул мозгами и пришел к выводу, что странно обращаться к связным таблицам, когда мы только-только сохранили главную запись.
Чуток не по теме, но все же.
В CActiveRecord в методе save вызывается afterSave до того, как установлен флаг isNewRecord=false. Поэтому в обработчике afterSave невозможно получить записи для related полей. Оно просто проверяет флаг isNewRecord и возвращает null для них, хотя для записи уже есть праймари ключ. Возможно это для чего-то сделано. Просто получается что вызов происходит не совсем after этого самого save.
Отсюда выходит, что зарядники надо делать умными, чтоб они мониторили какой кабель к ним воткнут и какое устройство. А потом повышали ток при согласии устройства. Если один преобразователь делать на квартиру, то он каждую розетку должен контролировать отдельно. В одну ноутбук с 90 Ватт запросами, в другую телефон.
Говоря о блокировках, есть еще вариант MySQL-specific. Где-то вычитал давно, не помню где. Смысл в том, что нужно получить именованую блокировку сервера и имя каким-то образом будет зависеть от ID выбираемой записи. Код примерно такой
SELECT *
FROM `queue`
WHERE GET_LOCK(CONCAT("my_queue_", id), 0)
LIMIT 1
id — первичный ключ в таблице. В persistent режиме вроде не будет работать без явного закрытия блокировки (не уверен, никогда не использовал). Если процесс внезапно помрет посреди обработки (и соединение закроется!), то блокировка отпускается.
Почтовый? тогда цифры не хватает одной. Да и по почтовому индексу слишком большой район. А улица такая действительно есть — 6,5. Вот то место goo.gl/maps/KdZd
Про невыразительность — да, строчки. Или многословность замыканий как на КДПВ.
А так, даже не знаю. Возможно я уже очень привык к обычной записи через foreach и прочие array_filter и новый подход тяжелее воспринимается, просто потому что не видно старых конструкций. А может я просто слишком консервативный в этом смысле.
В обычном php мне было бы видно сразу что происходит с данными, с какими именно частями и как они там оказались. И я даже могу это построчно отдебажить и проверить на каждом уровне. А тут, во-первых это новый синтаксис в котором прям вот сходу не поймешь что происходит и зачем. Лезем в доку, видим 50 методов… ух. Да, оно конечно выглядит прикольно, вроде так классно, но в вашем примере откуда-то взялась $v в строчках, непонятно как дебажить это дело. И вообще меня это пугает :)
Про расширение я не имел ввиду скорость, хотя это тоже плюс. А разве для ядерного уровня нельзя написать расширение? Тот же xdebug (zend_extension же) или опкод кешеры они не там работают? Вроде есть еще runkit, который позволяет заменять встроенные функции на что хочется. Так что я тут не уверен, что с помощью расширения нельзя привнести короткий синтаксис или синтаксические деревья. Ну и количество программистов — спорно. memcache/memcached расширение же ставят и ничего, не умирают. Не говоря уже о банальных php_mysql и прочем.
Я смотрю со своей колокольни, функциональщиной не интересовался, так что могу чего-то недопонимать в этой магии.
1. Но в итоге получаем еще большую невыразительность, разве нет?
Мне кажется, что чтобы такие вещи принести в PHP, нужно это все писать расширением, а не пытаться эффективно реализовать на самом языке.
Ну вы же понимаете, что там не забиты все места депутатами под завязку. Лето, дачи, да много всяких важных дел у депутатов. А пришедшие бегают по всему залу и нажимают кнопочки за всех остальных. Вот тут видать перестарались, нажали все «ЗА».
Метод называется insert. Внутри него после удачного собственно инсерта и проставления праймари ключа в модели вызывается вот что
А так да, afterSave вызывается и для insert, и для update. Но, мне кажется, можно параметром передавать вызываем мы его после добавления записи или обновления.
Это да, но проблема скорее архитектуры. Если я связные записи еще не сохранил, то и так вернется null записей.
Но в целом да, я уже пораскинул мозгами и пришел к выводу, что странно обращаться к связным таблицам, когда мы только-только сохранили главную запись.
В CActiveRecord в методе save вызывается afterSave до того, как установлен флаг isNewRecord=false. Поэтому в обработчике afterSave невозможно получить записи для related полей. Оно просто проверяет флаг isNewRecord и возвращает null для них, хотя для записи уже есть праймари ключ. Возможно это для чего-то сделано. Просто получается что вызов происходит не совсем after этого самого save.
id — первичный ключ в таблице. В persistent режиме вроде не будет работать без явного закрытия блокировки (не уверен, никогда не использовал). Если процесс внезапно помрет посреди обработки (и соединение закроется!), то блокировка отпускается.
А так все перечисленное уже есть.
А так, даже не знаю. Возможно я уже очень привык к обычной записи через foreach и прочие array_filter и новый подход тяжелее воспринимается, просто потому что не видно старых конструкций. А может я просто слишком консервативный в этом смысле.
В обычном php мне было бы видно сразу что происходит с данными, с какими именно частями и как они там оказались. И я даже могу это построчно отдебажить и проверить на каждом уровне. А тут, во-первых это новый синтаксис в котором прям вот сходу не поймешь что происходит и зачем. Лезем в доку, видим 50 методов… ух. Да, оно конечно выглядит прикольно, вроде так классно, но в вашем примере откуда-то взялась $v в строчках, непонятно как дебажить это дело. И вообще меня это пугает :)
Про расширение я не имел ввиду скорость, хотя это тоже плюс. А разве для ядерного уровня нельзя написать расширение? Тот же xdebug (zend_extension же) или опкод кешеры они не там работают? Вроде есть еще runkit, который позволяет заменять встроенные функции на что хочется. Так что я тут не уверен, что с помощью расширения нельзя привнести короткий синтаксис или синтаксические деревья. Ну и количество программистов — спорно. memcache/memcached расширение же ставят и ничего, не умирают. Не говоря уже о банальных php_mysql и прочем.
Я смотрю со своей колокольни, функциональщиной не интересовался, так что могу чего-то недопонимать в этой магии.
Мне кажется, что чтобы такие вещи принести в PHP, нужно это все писать расширением, а не пытаться эффективно реализовать на самом языке.