Comments 39
И где ссылка на issue?
Блин думал что добавил. Вот : https://github.com/laravel/framework/issues/351
Простите, полез в доку
https://www.postgresql.org/docs/current/sql-truncate.html
Пишут, что по дефолту - рестрикт
Или это ребята в Laravel напортачили?
Об этом и речь. Я привел цитату в посте, плюс можно по ишьюсу понять что они дичь сделали: https://github.com/laravel/framework/issues/35157
truncate здорового человека:
https://github.com/illuminate/database/blob/master/Query/Grammars/Grammar.php#L1397
public function compileTruncate(Builder $query)
{
return ['truncate table '.$this->wrapTable($query->from) => []];
}truncate курильщика:
https://github.com/illuminate/database/blob/master/Query/Grammars/PostgresGrammar.php#L631
public function compileTruncate(Builder $query)
{
return ['truncate '.$this->wrapTable($query->from).' restart identity cascade' => []];
}Зато всё по науке — переопределение базового метода в наследнике :)
Когда рад, что тебя с самого начала учили, что всегда всё переопределяй сам и никогда не полагайся на дефолты. Правда, это относилось к программам, особенно на МК, но, похоже, оно актуально даже с БД.
Спасибо, что поделились. Ни в коем случае не хочу набрасывать, просто личные эмиоции от прочитанного:
много кода и около 40 миграций и обновления зависимостей и новая конфигурация
Жесть. Гигантские релизы - зло. Вероятность того, что что-то пойдёт не так, крайне высока. Если есть возможность, всегда нужно стараться выкатывать код постепенно, пусть часть и не будет задействована в данный момент.
CASCADE приводит к тому, что
дропаются{очищаются} все связанные таблицы
Это более или менее интуитивно. Связь же строится на основе ключей. С чем связываться, если в родительской таблице все данные очищены?
Жесть. Гигантские релизы - зло. Вероятность того, что что-то пойдёт не так, крайне высока.
Вы абсолютно правы, но тут важен контекст, этот релиз делался всего три недели и его нужно было выкатывать отдельно. Проект почти что внутренний и носит некий технический характер.
> Это более или менее интуитивно. Связь же строится на основе ключей. С чем связываться, если в родительской таблице все данные очищены?
Это не дефолтное поведение. По дефолту транкейт не удаляет ничего в связанных таблицах. Ужас не только в том что они поменяли дефолтное поведение, но и еще и в том, что сделали это только для одного драйвера. В итоге получился не принцип наименьшего удивления, а принцип наибольшего удивления.
Это не дефолтное поведение. По дефолту транкейт не удаляет ничего в связанных таблицах.
Ирония ещё и в том, что и PostgreSQL, и MySQL, и MariaDB, и MS SQL Server, и (вероятно) даже SQLite не могут транкейтить таблицы, на которые через внешние ключи ссылаются другие таблицы. При этом, похоже, только у постгреса есть опция каскадного транкейта. Ей-то они и воспользовались.
Судя по всему, они столкнулись с багом транкейта для постгреса, но не проанализировали, что аналогичное может случиться и с другими СУБД. По-хорошему, им нужно было бы сделать дополнительную опцию truncate, а при отсутствии поддержки или эмулировать каскадный транкейт, или выбрасывать ошибку. То решение, которое они приняли — самое опасное и архитектурно непродуманное, но и самое лёгкое.
Я не первый раз наталкиваюсь на то, что главный в ларавеле принимает решения, которые вызывают удивление. Там много где в ишьюсах видно что люди годами с ним спорят про проверенные решения в других фреймворках, которые он отказывается добавлять. Иногда бывает что он сопротивляется по пять лет, потом понимает что надо и добавляет (как было со схемой базы)
Лучшее время для деплоя, по best practice, это вторник-среда.
Также хорошей практикой есть использование тестов во время деплоя. Такие тесты нужны как раз для того чтобы не удалить случайно данные из бд или чтобы не накатить нерабочий код.
Так как я работаю над проектом в выходные (я фаундер) и в это время пользователей нет, то для меня и безопасности это было лучшее время для деплоя
или чтобы не накатить нерабочий код.
покрытие кода тестами почти 90%. Только ситуация же к коду не имеет отношения, а на миграции тесты не пишут, подобные вещи видят визуально. В данном случае проект микроскопический и над ним никто фултайм не работает (это не проект даже, а так, сайд история к большому проекту), поэтому не заметили.
Пусть часть и не будет задействована в данный момент.
Релиз, в котором часть нового кода не используется и оставлена на будущее - очевидно злое зло. Если эта часть окажется багованной, то вместо проверки только изменений последнего патча, придется еще собирать подозреваемых по кускам из старых патчей.
фичефлаги придумали трусы? Например, нам (не Яндекс) надо поддерживать совместимость со старым кодом до момента окончания наката релиза, а это может затянуться на пару дней. Только после этого включается новый код. А включение кода интеграции со смежниками может затянуться на полгода - не по нашей вине, но нам надо быть готовыми подключиться по щелчку. А релизный цикл у нас месячный, с безой и прочими приседаниями
О как! А не подскажете, каскадное удаление использует метод класса модели (Model::truncate) или DB::table()->truncate() тоже?
А что, тестового/предрелизного стенда у вас нет? На нём бы сразу же проблема всплыла, не дошла бы до продакшена.
А для себя-то какие-то выводы сделали? Стали читать sql код генерируемый фреймворком? Подняли препрод и стали репетировать миграции на нём?
За мою довольно длинную карьеру, что-то подобное в миграциях произошло первый раз. Одна такая ситуация не причина отказываться от инструментария фреймворка, поэтому мы продолжим как действовали, но транкейта в миграциях больше не будет) Препрод нам не нужен, потому что 1) не тот контекст у проекта 2) мы учитывали этот риск, в выходные проект и так практически не работал и не будет работать (более того, это сезонный проект), поэтому все было по плану, просто чуть дольше по времени.
Making developers happy
Дичь какая-то. Зачем они это сделали
Много кода... 40 миграций...Деплой в субботу вечером...
Столько намеков было )))
Ну согласитесь что если я работаю над проектом в выходные, то логично его деплоить в выходные. Тем более это еще и совпадало с моментом, когда на проекте не было пользователей. А количество кода тут не важно, сама ситуация не подразумевала каких-то глобальных изменений, ну добавилось сущностей и крудов.
Какого было мое удивление
Тут, подозреваю, должно быть либо
"Какого х**!?" — было мое удивление
либо
Каково было мое удивление
Делать деплой в выходной день - это вообще диверсия)
Странно, что при выполнении миграции никто не просматривает, что будет выполнено.
Как я положил продакшен базу на выходных