SZ
дайошь php vm на rust
щас ffi guy призовешь в чат)
Size: a a a
2020 August 05
K
представим ситуацию: подготовили новый функционал, все протестировали, все вроде ок. выкатываем на прод. собрали докер образ, пометили тегами, все сделали. переключили трафик потихоньку на новую систему, но что-то пошло не так. начали падать ошибки в лог / сервера перестали вывозить нагрузку. было решено откатываться, и разбираться в проблеме. но вот незадача: на базу накатились миграции. если вернуть старый код на эту базу - он работать не будет. будут другие баги. надо откатывать миграции. но при этом произошло удаление столбца / таблицы. если ревертнуть миграции, то структура восстановится на предыдущее состояние, но данные уже нет. как быть? заливать дамп, сделанный перед переключением? но тогда произойдет потеря данных, возникших во время работы системы в новой забагованной версии. факап, выхода нет? или таки есть?
У меня в практике был подход - ни за что не дропать поля
K
Ну и естественно перед миграциями делаются дампы
K
Бывало что и юзеру бд в целом alter запрещался 😄
K
И миграции дба делали на своё усмотрение. Дико? Да. Но там терабайты финансовой инфы были.
K
И в случае факапа можно было смело идти в окно
SP
Да, пусть dba идёт в окно
SP
Люблю это перекладывание ответственности вместо решения проблем
VM
Katulos⠀
У меня в практике был подход - ни за что не дропать поля
это конечно прикольно, но в новых записях в это поле ничего не пишется и в случае реверта они остануться пустыми
это не говоря о том, что поле может быть not null и тогда вообще не получится ничего
это не говоря о том, что поле может быть not null и тогда вообще не получится ничего
АГ
not null лучше потом выставлять, вместе с чисткой старья. ну а если прям надо - то 3 шага: 1) создать нуллабл столбец 2) заполнить его апдейтом 3) сделать нот нулл, ну либо сразу default значение прописать, как альтернатива
VM
дефолтное значение не всегда подходит
новые записи окажутся с незаполненным полем, так что в случае реверта будет больно
новые записи окажутся с незаполненным полем, так что в случае реверта будет больно
АГ
если нужен реверт кода, то поле надо делать nullable и все
VM
но данные там не появятся =)
АГ
ну в случае с откатом системы, эти поля не будут использоваться, и надо только чтобы их наличие не сломало старую версию системы
DP
отсутствие данных тоже может сломать систему, в этом проблема
DP
недостаточно только колонки иметь, данные тоже могут быть важны, особенно если код писали не астронавты, а живые люди, которым свойственно разгильдяйство, отсутствие проверок и бездумный method chaining, например
VM
недостаточно только колонки иметь, данные тоже могут быть важны, особенно если код писали не астронавты, а живые люди, которым свойственно разгильдяйство, отсутствие проверок и бездумный method chaining, например
вот как раз будет скоро
$this->repo->getUser()?->getContactInfo()?->getPhoneNumber()
$this->repo->getUser()?->getContactInfo()?->getPhoneNumber()
VS
Volodymyr Melko
вот как раз будет скоро
$this->repo->getUser()?->getContactInfo()?->getPhoneNumber()
$this->repo->getUser()?->getContactInfo()?->getPhoneNumber()
Может лучше $this->rep->getUser()?->getPhoneNumber()
VM
может и лучше, я просто хотел продемонстрировать утрировано, что длинные цепочки вызовов никуда не денутся, а просто обрастут знаками вопросов =)
DA
Привет всем. Вопрос такой:
1. Есть Class extends Parent
2. Есть Parent
3. Есть Connector который собирается и используется в Class
4. В Connector собирается класс Request
Если я хочу в коннекторе поймать исключение - а в Class и Parent есть try catch на такое же исключение, если оно поймается в Connector, поймается ли оно в Class и Parent?
1. Есть Class extends Parent
2. Есть Parent
3. Есть Connector который собирается и используется в Class
4. В Connector собирается класс Request
Если я хочу в коннекторе поймать исключение - а в Class и Parent есть try catch на такое же исключение, если оно поймается в Connector, поймается ли оно в Class и Parent?