АС
главное - не сделать каскад триггеров
Size: a a a
2020 August 05
АГ
да их вообще, как и хранимок, быть не должно) разве что в случае если "прям очень надо, и по-другому никак"
АС
да их вообще, как и хранимок, быть не должно) разве что в случае если "прям очень надо, и по-другому никак"
ахаха
АГ
но вместе с созданием триггера / хранимки надо ставить задачу на избавление от них, и думать... если сразу не придумалось)
АС
в файлики пишите тогда данные
АГ
ну почему же, эластик, кликхаус, редис - вполне годные вещи)
DE
да их вообще, как и хранимок, быть не должно) разве что в случае если "прям очень надо, и по-другому никак"
Либо без триггеров делать на уровне PHP-кода, чтобы новый код лазил в обе колонки. Но это тоже сложнее.
DP
и другой вопрос, связанный с этим: как реализовать откат на старую версию так, чтобы не было даунтайма? надо сначала откатить миграции, которые есть только в новом коде, при этом система временно попадет в неработоспособное состояние. затем запустить предыдущий образ приложения. какие для этого можно использовать инструменты? kubernetes?
для простых проектов очень неплох Envoyer
АГ
Либо без триггеров делать на уровне PHP-кода, чтобы новый код лазил в обе колонки. Но это тоже сложнее.
ну такой триггер, как временное решение - это другое дело, надо просто ставить задачу на избавление от этих временных заглушек, прописывать сроки и условия, следить за выполнением этих задач.
SP
Да, делать миграции так, чтобы работал и старый код, и новый. Тогда откатывать не придётся.
Например, если надо переименовать поле, то вместо RENAME колонки мы первой миграцией делаем ADD + UPDATE и вешаем триггер для синхронизации новой колонки со старой. И теперь деплоим новый код.
В итоге старый код продолжает работать со старой колонкой, а новый уже пробует работать с новой.
А потом через неделю когда всё новое точно работает спокойно делаем DROP старого поля и триггера.
Например, если надо переименовать поле, то вместо RENAME колонки мы первой миграцией делаем ADD + UPDATE и вешаем триггер для синхронизации новой колонки со старой. И теперь деплоим новый код.
В итоге старый код продолжает работать со старой колонкой, а новый уже пробует работать с новой.
А потом через неделю когда всё новое точно работает спокойно делаем DROP старого поля и триггера.
Аналогично только синхронизация происходит на уровне кода.
NO
после чего спокойно выкатывайте "новый" код
тестируйте
и ставьте задачу на "схлопывание" состояния
тестируйте
и ставьте задачу на "схлопывание" состояния
Двухшаговая миграция, идеальный вариант ) Делаю так, когда что-то критичное меняется.
NO
Похожий подход использую, кстати, с подключением новых внешних сервисов или например пакетов композера.
Выкатываю новый код на сервер вместе со старым.
При этом прод продолжает работать на старом коде, а новый код доступен в ручном режиме через консоль.
Прописываю все настройки, убеждаюсь что новый код заработал на проде. Потом более-менее спокойно переключаю прод на новый код )
На следующий день старый код можно удалять, если ничего не упало.
Но это если что-то критичное меняется, что весь сервис затрагивает. В таких случаях лучше перебдеть )
Выкатываю новый код на сервер вместе со старым.
При этом прод продолжает работать на старом коде, а новый код доступен в ручном режиме через консоль.
Прописываю все настройки, убеждаюсь что новый код заработал на проде. Потом более-менее спокойно переключаю прод на новый код )
На следующий день старый код можно удалять, если ничего не упало.
Но это если что-то критичное меняется, что весь сервис затрагивает. В таких случаях лучше перебдеть )
NO
Да, делать миграции так, чтобы работал и старый код, и новый. Тогда откатывать не придётся.
Например, если надо переименовать поле, то вместо RENAME колонки мы первой миграцией делаем ADD + UPDATE и вешаем триггер для синхронизации новой колонки со старой. И теперь деплоим новый код.
В итоге старый код продолжает работать со старой колонкой, а новый уже пробует работать с новой.
А потом через неделю когда всё новое точно работает спокойно делаем DROP старого поля и триггера.
Например, если надо переименовать поле, то вместо RENAME колонки мы первой миграцией делаем ADD + UPDATE и вешаем триггер для синхронизации новой колонки со старой. И теперь деплоим новый код.
В итоге старый код продолжает работать со старой колонкой, а новый уже пробует работать с новой.
А потом через неделю когда всё новое точно работает спокойно делаем DROP старого поля и триггера.
В книге "эволюционная архитектура" такая методика описывается ) Логичный подход )
F
2020 год, а люди снова изобретают многофазные миграции (:
DE
FOX
2020 год, а люди снова изобретают многофазные миграции (:
Не изобретают
I
Добрый день. Я не программист, но активно его ищу. Подскажите, пожалуйста, Как найти на сдельщину программиста на рнр. Есть сайт и срм система, которые достались в наследство при покупке фирмы. И там все на самописном движке. Как найти программиста, который в ответственный момент не бросит - не знаю :( отчаянность и безысходность. Может быть либо здесь есть люди, кому интересно, либо кого-то можете посоветовать.
А
Добрый день. Я не программист, но активно его ищу. Подскажите, пожалуйста, Как найти на сдельщину программиста на рнр. Есть сайт и срм система, которые достались в наследство при покупке фирмы. И там все на самописном движке. Как найти программиста, который в ответственный момент не бросит - не знаю :( отчаянность и безысходность. Может быть либо здесь есть люди, кому интересно, либо кого-то можете посоветовать.
SZ
https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/ nikic уже и тут активно отмечается)
КГ
https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed-up-the-rust-compiler-some-more-in-2020/ nikic уже и тут активно отмечается)
дайошь php vm на rust