StalkerClasses
Новичок
Ребят напишите или скиньте пожалуйста список что изучить что почитать что бы развиться как php программист (backend) в том числе по фреймворкам. Спасибо.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Жить без миграций Laravel // Yii2
- Автор темы StalkerClasses
- Дата начала
у тебя база с 100500 клиентами, с оборотом сотни мио в год, поставщиками и и и, (не дай бог что пойдет не так)
эта миграция проиграется десятки раз до того как попасть в prod, каждый разработчик после обновления запустит ее на своем окружении.
так понятно?
нужно добавить фичу, для этого нужно сделать изменения в структуре данных. эти изменения пишут в миграцию. все
я не удаляю не изменяю базу руками, я делаю git push а то что ты описываешь делает уже deploy-script и только после того как все 40 раз перетестится, получит одобрение всех кто указан в pull-request, а таже вышестоящих.
эта миграция проиграется десятки раз до того как попасть в prod, каждый разработчик после обновления запустит ее на своем окружении.
так понятно?
StalkerClasses
Новичок
Вот про что спрашивал:
github.com
Миграции и демо-данные можно создать в самой модели...
Правда не понятно как менять и удалять колонки...
Возможно как-то можно.
Чем это хуже обычных миграций?
GitHub - legodion/lucid: Declare database migrations and factory definitions inside Laravel models.
Declare database migrations and factory definitions inside Laravel models. - GitHub - legodion/lucid: Declare database migrations and factory definitions inside Laravel models.
github.com
Правда не понятно как менять и удалять колонки...
Возможно как-то можно.
Чем это хуже обычных миграций?
StalkerClasses
Новичок
Все таки я попробую и посмотрю что будет.
Хотя бы вот этот плагин. И посмотрю как он работает.
Не пойму - миграции это история изменения структуры БД.
Но и эти файлы моделей я смогу посмотреть в git. Какая разница?
Мне например не удобно создавать миграции... каждый раз нужно вспоминать как написать название миграции на добавление, изменение, удаление колонки.
Тугай
Новичок
Миграция это не история изменения, а программа которая тебе обновит бд с версии 1.0 приложения, на версию 2.0.
История это то что было, а миграция как из старого сделать новое.
Без миграции тебе придется реализовывать иморт/экспорт данных между версиями.
Пока версию 1.0 не напишешь миграции тебе не нужны.
Это не для твоего удобства, а для удобства того кто захочет обновится на новую версию и у которого есть старая.
История это то что было, а миграция как из старого сделать новое.
Без миграции тебе придется реализовывать иморт/экспорт данных между версиями.
Пока версию 1.0 не напишешь миграции тебе не нужны.
Это не для твоего удобства, а для удобства того кто захочет обновится на новую версию и у которого есть старая.
StalkerClasses
Новичок
Здесь речь идет о том, почему нельзя миграции описать в модели?Миграция это не история изменения, а программа которая тебе обновит бд с версии 1.0 приложения, на версию 2.0.
История это то что было, а миграция как из старого сделать новое.
Без миграции тебе придется реализовывать иморт/экспорт данных между версиями.
Пока версию 1.0 не напишешь миграции тебе не нужны.
Это не для твоего удобства, а для удобства того кто захочет обновится на новую версию и у которого есть старая.
И точно также их вызывать...
Если их описывать в модели - то не надо вот все эти файлы создавать бла бла бла дата такая, что сделал и т.д. и т.п.
Valick
Новичок
StalkerClasses, вот почему у тебя такая безудержная тяга делать всё через жопу?
Миграции не вчера придумали, и они решают кучу рутинных проблем. Грубо говоря если ты будешь развивать свою идею дальше, то через пару лет напишешь жалкое подобие механизма миграций. А можешь не ... вола, а взять и использовать готовое уже сейчас.
Миграции не вчера придумали, и они решают кучу рутинных проблем. Грубо говоря если ты будешь развивать свою идею дальше, то через пару лет напишешь жалкое подобие механизма миграций. А можешь не ... вола, а взять и использовать готовое уже сейчас.
StalkerClasses
Новичок
Я не собираюсь ничего писать, изобретать велосипед или использовать через ж.
GitHub - legodion/lucid: Declare database migrations and factory definitions inside Laravel models.
Declare database migrations and factory definitions inside Laravel models. - GitHub - legodion/lucid: Declare database migrations and factory definitions inside Laravel models.
github.com
Вот что я нашел по авто-миграциям - мне эта идея гораздо больше нравится чем просто создание отдельных файлов миграций...
Я еще не пробовал это решение.
Вот по миграциям что вам дает откат допустим на 10 миграций назад?
Ну восстановили вы колонку - а на продакшине вы как данные восстановите?
Давай, напиши пример, мы посмотрим
StalkerClasses
Новичок
Хорошо - у меня есть как раз реальный пример моделей на которых я подписал исполнительную документацию по Шереметьево. Я попробую сделать на вот таких авто миграциях модели на моем сайте и посмотрим что получится.
А также попробую добавить колонку, удалить колонку. С переименованием таблицы правда не знаю как она поймёт что переименовано.
StalkerClasses
Новичок
Реально не понимаю что вам всем даёт откат на 10-15-100 миграций назад?
StalkerClasses
Новичок
Откатывался то все равно придётся в гит бегать и смотреть что там было.
Атомарность операции, их можно откатывать до того места, до которого надо. И надо понимать что удаление колонки - это крайний случай, отката этому с восстановлением данных и не должно быть.
Откат это редкая вещь, чаще случается в процессе разработки, чем в продакшне.
StalkerClasses
Новичок
Немного подкорректирую тему, я не говорю без них а говорю за способ как они создаются и описываются.
StalkerClasses
Новичок
Ну вот вы откатили скокото а что вам это даёт? В продакш все равно пойдёт ++ миграции и все ваши изменения.
Я же описал для чего это надо, для того, чтобы N людей в команде могли делать атомарные изменения в структуре БД, но ты все время везде работал один, тебе не понять.
Если надо, допустим возник какой-то конфликт в результате разработки - люди взяли, откатили все назад и созвонившись решили как поправить свои миграции, потом прогнали тесты, потом смержили в релиз и выложили.
Без миграций ты руками будешь восстанавливать структуру БД чтобы потом снова ее менять?
Если надо, допустим возник какой-то конфликт в результате разработки - люди взяли, откатили все назад и созвонившись решили как поправить свои миграции, потом прогнали тесты, потом смержили в релиз и выложили.
Без миграций ты руками будешь восстанавливать структуру БД чтобы потом снова ее менять?
StalkerClasses
Новичок
Мне всегда очень нравились базы данных с их устройством, но я никогда не понимал почему в php коде они имеют такую нагромождению недоаьстракцию в сравнении например с теми же классами для работы с файлами где все прозрачно.
А здесь одно то что в модель вставляются данные без аксессоров. Меняя имя колонки таблицы Ее еле надо найти во всех кусках кода. Умудрится. А была бы оформлена как метод все же проще. Возможно я еле с симфони не работал )
А здесь одно то что в модель вставляются данные без аксессоров. Меняя имя колонки таблицы Ее еле надо найти во всех кусках кода. Умудрится. А была бы оформлена как метод все же проще. Возможно я еле с симфони не работал )
наоборот, от последнего дампа и по цепочки вперед... rollback это только на свои косяки
StalkerClasses
Новичок
В битрикс нет миграций как то жили.
Модель = Таблица. Соответственно модель может содержать всю актуальную информацию структуре.
Вот вы откатились а код все равно нужно по гиту откатывать.
А так я нажал на историю изменённой модели и все вижу.