А
_attributes это массив ?
object(Excel)[17]
public '_attributes' =>
array (size=5)
public '_attributes' =>
array (size=5)
Size: a a a
2020 May 12
Д
Да.
А какого тогда ляха ты юзаешь его как объект ?? _attrıbutes->$name ?
Д
Может надо [$name] ?
А
А какого тогда ляха ты юзаешь его как объект ?? _attrıbutes->$name ?
$tempArray = (array)$this->_attributes;
foreach($tempArray as $name => $value) {
if (!empty($tempArray[$name])) {
$array[$name] = $value;
}
}Д
На ты спросил почему он ругался на строку. Я объяснил. Дальше сам.
А
На ты спросил почему он ругался на строку. Я объяснил. Дальше сам.
Я это понял.
А
А так юзают $this->$name?
Д
А так юзают $this->$name?
Коротко - да. Длинно : https://stackoverflow.com/questions/804850/get-php-class-property-by-string
A
А так юзают $this->$name?
да, но это другой случай. и этим лучше не злоупотреблять.
O
Коротко - да. Длинно : https://stackoverflow.com/questions/804850/get-php-class-property-by-string
А
да, но это другой случай. и этим лучше не злоупотреблять.
В каких случаях пользуются?
TS
Лучше не переписывай так)
Это почему? Очень здорово получается.
NO
Это почему? Очень здорово получается.
Ну если у тебя проверка уникальности завязана на ошибку FOREIGN KEY в БД, ты во-первых, не сможешь этот кейс нормально протестировать без БД, во-вторых может очень неожиданно вылезти побочный эффект.
Например, кто-то добавил код отправки уведомления менеджеру при сохранении. Уведомление отправляется перед сохранением. При ошибке уникальности, у тебя отправится уведомление, а только потом сработает ошибка. Итого, пользователь 9 раз сохранил с ошибкой, один раз успешно, а уведомлений отправилось 10 вместо 1.
Гораздо лучше, если валидация идёт перед сохранением в БД, как в обычном валидаторе. В указанном примере, мы просто вызовем $model->validate() заранее, и в случае ошибки не будем ни уведомление отправлять, ни в базу записывать.
Например, кто-то добавил код отправки уведомления менеджеру при сохранении. Уведомление отправляется перед сохранением. При ошибке уникальности, у тебя отправится уведомление, а только потом сработает ошибка. Итого, пользователь 9 раз сохранил с ошибкой, один раз успешно, а уведомлений отправилось 10 вместо 1.
Гораздо лучше, если валидация идёт перед сохранением в БД, как в обычном валидаторе. В указанном примере, мы просто вызовем $model->validate() заранее, и в случае ошибки не будем ни уведомление отправлять, ни в базу записывать.
NO
В общем, ты что ты переписываешь, выглядит как замена здорового кода на костыли.
NO
И кстати непонятно зачем. Чтобы сэкономить 1 запрос к БД? )
TS
Ну если у тебя проверка уникальности завязана на ошибку FOREIGN KEY в БД, ты во-первых, не сможешь этот кейс нормально протестировать без БД, во-вторых может очень неожиданно вылезти побочный эффект.
Например, кто-то добавил код отправки уведомления менеджеру при сохранении. Уведомление отправляется перед сохранением. При ошибке уникальности, у тебя отправится уведомление, а только потом сработает ошибка. Итого, пользователь 9 раз сохранил с ошибкой, один раз успешно, а уведомлений отправилось 10 вместо 1.
Гораздо лучше, если валидация идёт перед сохранением в БД, как в обычном валидаторе. В указанном примере, мы просто вызовем $model->validate() заранее, и в случае ошибки не будем ни уведомление отправлять, ни в базу записывать.
Например, кто-то добавил код отправки уведомления менеджеру при сохранении. Уведомление отправляется перед сохранением. При ошибке уникальности, у тебя отправится уведомление, а только потом сработает ошибка. Итого, пользователь 9 раз сохранил с ошибкой, один раз успешно, а уведомлений отправилось 10 вместо 1.
Гораздо лучше, если валидация идёт перед сохранением в БД, как в обычном валидаторе. В указанном примере, мы просто вызовем $model->validate() заранее, и в случае ошибки не будем ни уведомление отправлять, ни в базу записывать.
Ну и что? Протестирую с БД. Тесты делаются для приложения, а не приложение для тестов.
То, что вызывать нужно в некоем контектсе - это да, но в фреймворке много чего нужно вызывать в жестком контексте.
Просто у нас несколько другой контекст, для на. более оптимальный.
Сэкономить можно не один, а под десяток запросов.
Данные у нас обычно очень ветвистые.
Так что, у всего есть своя область применения...
То, что вызывать нужно в некоем контектсе - это да, но в фреймворке много чего нужно вызывать в жестком контексте.
Просто у нас несколько другой контекст, для на. более оптимальный.
Сэкономить можно не один, а под десяток запросов.
Данные у нас обычно очень ветвистые.
Так что, у всего есть своя область применения...
TS
Кстати, совсем забыл - так сделать пришлось еще и потому, что на одной нагруженной системе были гонки - Там был сервер чтения и сервер записи, так вот были случаи, когда валидация проходила, в этот момент данные измнялись и запись падала.
NO
Даже если десяток... Никогда не встречал, чтобы это было узким местом в приложении.
TS
Даже если десяток... Никогда не встречал, чтобы это было узким местом в приложении.
Если стоит задача малого времени ответа - то это и есть узкое место. И дергать сервер ради проверки нерационально.
NO
Вообще стандартная практика при мастер-слейв, когда пишется в мастер БД, а читается со слейва БД (реплики), делается так.
Запросы (пользователя к приложению) делятся на два типа.
1. Первые - без побочных эффектов, только чтение. Они идут на слейв.
2. Вторые - с побочными эффектами, меняющие состояние системы. Там может быть как чтение, так и запись. Так как данные на слейве могут отставать от мастера, то все запросы к БД из запросов приложения второго типа идут на мастер. Как чтение, так и запись.
Запросы (пользователя к приложению) делятся на два типа.
1. Первые - без побочных эффектов, только чтение. Они идут на слейв.
2. Вторые - с побочными эффектами, меняющие состояние системы. Там может быть как чтение, так и запись. Так как данные на слейве могут отставать от мастера, то все запросы к БД из запросов приложения второго типа идут на мастер. Как чтение, так и запись.