Евгений
спасибо, посмотрю
Евгений
Друзья! Помогите пожалуйста настроить docker phpstorm xdebug.
Евгений
Nikolay
У вас сервер настроен? (PHP -> Servers)
Евгений
Да
Евгений
У вас сервер настроен? (PHP -> Servers)
Николай здравствуйте! Скажите пожалуйста, вы сейчас пользуетесь docker xdebug?
Евгений
Спасибо. С праздником!
Thawne
Всем привет, такой вопрос, у меня есть таблица customer и job, и я пытаюсь получить список клиентов с их заказами. Как видно на скрине я четко указал что мне нужен только job с id 41534 но он мне вытаскивает все job’ы клиента🤔
Денис
Всем привет, такой вопрос, у меня есть таблица customer и job, и я пытаюсь получить список клиентов с их заказами. Как видно на скрине я четко указал что мне нужен только job с id 41534 но он мне вытаскивает все job’ы клиента🤔
Ты что получаешь на выходе? Кастомера? А у кастомера уже потом запрашиваешь джобы. А в этом запросе на скрине ты только выбираешь тех качтомеров, у которых есть указанная джоба
Денис
Если тебе нужна одна конкретная джоба, то и получай ее в соответствующем репозитории
Корочка
Ребята, всем привет. Не подскажете пожалуйста, может кто знает как Phpstorm сделать git checkout -- .
Корочка
Корочка
а что мешает команду сделать в консоли?
А вообще просто прожать forced push надо после того как сделали ресет в phpstorm, а в консоли можно вот так сделать и все git checkout -- .
Денис
Товарищи. Есть мнение, что среди нас завелся спамер
Денис
Нужно его вычислить
Max
да и еще с премиум подпиской)
Sergey
Не знаю о ком вы. Даже подозрения нет.
Nikolay
Привет всем, есть такой спорный вопрос по миграциям, нужно ли писать откат для миграции, которая обновляет данные. Я считаю, что это нецелесообразно и просто трата времени. Подскажите, что можно почитать по этой теме, чтобы убедиться, что я неправ
Sanan
а в связи с чем эта миграция была создана? вместе с каким то функционалом, который эти данные использует, или это просто данные, и от них ничего не зависит?
Sanan
что будет если ты в откате миграции откатишь эти изменения? на что это повлияет?
Sanan
если эти изменения ни на что не влияют, и откат их не может как либо пагубно отразится на системе, которая их использует, и при их откате ничего не случится критического, то думаю, можно смело писать миграцию на откат
Иван
ценность ролбеков крайне ограниченная
Sanan
он мог там что то накодить, что может использовать эту версию миграции
Sanan
например какой нибудь енам
Sanan
и при откате миграции по бд, надо и версию приложения откатить
Sanan
надо смотреть связана ли миграция с функционалом приложения
полагаю, это по крайней мере "good practices", раз там оно есть..
Nikolay
полагаю, это по крайней мере "good practices", раз там оно есть..
Просто на одном месте работы писали только для изменения структуры, мне кажется это логично было
Sanan
Цены поменялись
в этом случае можно писать пожалуй откат
Nikolay
в этом случае можно писать пожалуй откат
А зачем, если вероятность его использования 1% из 100? На это просто лишнее время тратиться
Sanan
ну по такой логике можно вообще откатывающие миграции не писать
Nikolay
Если цены снова поменяются то это уже будет новая миграция
Nikolay
и вы что, прям захардкодили их в миграцию?.
Да, такие данные меняются очень редко
Миграции никак не связаны с доктриной, они могут сами по себе быть
мы как будто о разных миграциях говорим. я об вот этих
Да, такие данные меняются очень редко
я бы в любом случае их вынес тогда в какие-то константы, или переменные окружения, и в БД не пихал. раз они так редко меняются. 🤷‍♂
Nikolay
мы как будто о разных миграциях говорим. я об вот этих
Я про эти же, миграции это не только изменение схемы
Pavel
Раз уж эти данные так редко меняются - меняйте ручками запуская запрос, зачем вам для этого миграции? Миграции нужны для поддержания актуальности схемы данных, а не изменения самих данных, особенно не константных. В крайнем случае напишите себе консольную команду, которая будет обновлять нужные данные..
Pavel
Иначе это у вас не список миграций, а история sql запросов какая то
Pavel
Которая еще и в репозитории хранится
Которая еще и в репозитории хранится
кстати да. вы туда ещё ключи для АПИ положите, они ж тоже нечасто меняются 😏
The Ant
Привет всем, есть такой спорный вопрос по миграциям, нужно ли писать откат для миграции, которая обновляет данные. Я считаю, что это нецелесообразно и просто трата времени. Подскажите, что можно почитать по этой теме, чтобы убедиться, что я неправ
откат не нужен в принципе, потому что откат это изменение бд, а изменение бд это миграция. Т.е. накатываем новые миграции всегда, в том числе для отката в старое состояние
Павел
откат не нужен в принципе, потому что откат это изменение бд, а изменение бд это миграция. Т.е. накатываем новые миграции всегда, в том числе для отката в старое состояние
Не понятно как тогда делать ролбэк. В случае с существованием отката: - откатывается БД по down в миграции - откатывается код. Как без down? Вроде нужно и код откатить, а вроде и новую миграцию, на откат той миграции, которой не будет в старом коде и все крашнется, если поднять проект с 0.
Павел
а код откатывается?
Ну когда делаетс релиз, там же не одна миграция на весь релиз
The Ant
по моему все делают быстрофиксы )
Павел
по моему все делают быстрофиксы )
Ну тут уже видимо у каждого своя стартегия
Павел
Если можно сделать быстро фикс, то лучше его. А если нельзя или проблема не понятна?
The Ant
что делать когда во время миграции меняются данные? например после енама откат невозможен обычным запросом, там ебанина будет
The Ant
имеюв виду енам -> инт тип колонки
Павел
Не делать енамы в БД)
The Ant
в любом случае, случайно не роллбекнуть миграцию надо делать новую, это будет осмыселнный шаг
Павел
Ну а вообще надо конкретные кейсы и конкретные проекты рассматривать, где то и даун проекта возможен на "технический перерыв"
The Ant
ну крч даун миграции для педиков ) это сразу потенциальные проблемы куда хуже чем небольшой факап в коде, вплоть до проеба всех данных
Ivan
Всем привет! Пробую использовать Baldinof/roadrunner-bundle. Столкнулся с проблемой с сессиями, что они пересоздаются каждый раз заново, причём это поведение проявляется в prod режиме. В dev работает корректно. Изменение поведения kernel_reboot strategy на always ни к чему не приводит. Помогает только установка http.pool.num_workers=1. Никто не сталкивался?
Vlad
а сессии где лежат?
Ivan
Redis
Max
Всем привет! Пробую использовать Baldinof/roadrunner-bundle. Столкнулся с проблемой с сессиями, что они пересоздаются каждый раз заново, причём это поведение проявляется в prod режиме. В dev работает корректно. Изменение поведения kernel_reboot strategy на always ни к чему не приводит. Помогает только установка http.pool.num_workers=1. Никто не сталкивался?
Если количество воркеров помогло, значит пользователь попадает на второго воркера и создаётся новая сессия. Редис используете через кэш симофни? Он хранит полученные данные из кэша в памяти. Может в этом дело? Можно попробовать использовать KV роадраннера, но там будет общий кэш только между воркерами
Max
Еще отличие dev от prod это количество job-ов В dev = 1, а в prod сколько укажешь
Max
Все верно! Redis использую через кэш симфони, т.к. сессии тегирую дополнительно.
Если что, то я не смог почистить память у этого кэша) Очистка есть, но нифига не работает. Я бы предложил дебажить в prod, но в логировании указать PID процесса, что бы понимать что за воркер
Ivan
Я видел у этого bundle вот такой middleware, https://github.com/Baldinof/roadrunner-bundle/blob/2.x/src/Integration/PHP/NativeSessionMiddleware.php И предполагал, что сессия будет восстановлена из куки. И от количества workers вроде как не должно зависеть?
Ivan
Не могу подсказать, не юзал
Спасибо, буду пробовать дальше)
Max
В чате разрабов RR часто помогают с таким