1. Скажите, пожалуйста, чем отличаются миграции от доктрины, и их практическое применение?
Может, книжку хорошую посоветуйте, желательно на русском. Я так поняла, они оба генерируются, и бд обновляется, создается.
Миграции генерируются , как я поняла, на основе файлов миграции, а доктрина - на основе сущностей. В миграции, как я поняла, нельзя задать столбцу тип varchar, а для доктрины можно. 2. Выходит, доктрина дополняет миграции? 3. И в каком порядке тогда работают доктрины и миграции?
Миграции - это последовательность модифицирующих запросов к базе.
Доктрина - это ORM, способ работы с реляционными данными через обьекты.
P.S. Не рекоммендую делать миграции на базе ORM. Представим сценарий миграции
1. Создать таблицу пользователей
2. Переименовать таблицу пользователей в клиентов
3. Добавить столбец с таблицу клиентов.
ORM представляет из себя проекцию текущего состояния структуры базы. Поэтому повторить миграции на другом базе, состояние которой находится на первом этапе не получится, так как маппинг кода будет ссылатся на третий шаг
Миграции - это последовательность модифицирующих запросов к базе.
1.Какие модифицирующие запросы, как я поняла, миграции изменяют только схему бд?
2.То есть, доктрина позволяет обращаться к таблице сущности, как классу?
Подскажите, пожалуйста, порядок действии, в случаях А и Б:
А) создание таблицы posts (id, title)
Б) Добавление колонки в posts (img)
Что сначала делаем, доктрину или миграцию? Подскажите, плиз, с чего бы вы начали?
Еще момент, если я меняю последнюю миграцию, уже сгенерированную, то почему-то не работает текущая миграция? Поэтому я создаю новые миграции с измененными данными. Возможно, в этом и есть отличие от доктрины , сущность можно менять бесконечно число раз, а миграции только добавлять...
Все равно темный лес в голове, зачем их нужно применять одновременно, какая польза?
1. Не только структуру. Миграция может и данные добавлять. Например "создать категории по умолчанию"
2. Да
3. Создать две миграции, а потом создать ORM на базе текущей структуры.
P.S. Я противник того чтоб ORM "создавало" или "модифицировало" структуру само. Структура должна формироваться с помощью миграций, а ORM обновляться в соответсвии с текущей структурой.
Hfnas, использование доктрины подразумевает создание сущности, а затем генерацию на ее базе миграции
В вашем случае:
А)
- создаем сущность posts (id, title)
- генерируем миграцию (проверяем и при необходимости редактируем)
Б)
- добавляем поле posts (img)
- генерируем миграцию (проверяем и при необходимости редактируем)
Ninazu Не много не понял что имелось в виду "делать миграции на базе ORM". Полагаю использовать "doctrine:schema:update"?
3. Создать две миграции, а потом создать ORM на базе текущей структуры.
1.то есть, я сделала 2 миграции - в бд таблички были созданы- и на основе таблиц в бд, генерируются сущности? так?
2.Далее, я захотела добавить еще столбец author в табличку posts , я создаю миграцию- генерирую- бд обновилась- обновляю сущность на основе бд опять генерауией orm?
3.Еще один вопрос, сущности пишутся вручную? я почему-то думала, что класс сущностей надо руками заполнять. Это так?
1. Да
2. Да
3. Нет. Обычно существуют генераторы, которые синхронизируют сами структуру и класс.
Но еще раз повторюсь, что я противник ORM. Если хотите следовать по пути моделей и ORM, то лучше по пути BoShurik следовать.
P.S. В последнее время работаю с большими обьемами данных. И популяризация в обьекты чрезмерно избыточна. Про добавление столбца в живую базу, с миллиардной таблицей я вообще молчу. Поэтому избавляюсь от этих технологий. Хотя для маленького проекта или на его начальном этапе можно использовать, а потом переписывать критические участки)
3. Да, они пишутся вручную :)
Можно сгенерировать из БД, но это одноразовая операция, которая используется при переносе проекта на доктрину. Дабы не быть голословным: https://www.doctrine-project.org/projects/doctrine...
Reverse Engineering is a one-time process that can get you started with a project. Converting an existing database schema into mapping files only detects about 70-80% of the necessary mapping information. Additionally the detection from an existing database cannot detect inverse associations, inheritance types, entities with foreign keys as primary keys and many of the semantical operations on associations such as cascade.
BoShurik, Ninazu, вы походу противоречите друг другу...или я Вас не понимаю...
Правда, в книжке https://olegkrivtsov.github.io/
1. создаются таблицы
2. создаются сущности вручную, по-видимому
3. следующая глава посвящена миграции
Про генерацию миграции вроде поняла, как делать. Про сущность не совсем. Сейчас попробую удалить сущности, и сгенерировать на основе бд - проверю, создадутся ли самостоятельно сущности?
И популяризация в обьекты чрезмерно избыточна. Про добавление столбца в живую базу, с миллиардной таблицей я вообще молчу. Поэтому избавляюсь от этих технологий.
то есть вы используете только прямые запросы в бд, без всяких там миграции и доктрин в больших проектах?
Hfnas, Любые изменения в базе, в обход интерфейса идут через миграции. Миграции из себя представляют файлы с запросами к базе и таблицу состояний применённых к базе миграций. Миграции выполняет отдельный скрипт который отвечает за обновление кода, дополнительные сценарии и он же заносит применённые миграции в соответсвующую таблицу. Модели и Doctrine не используем. Есть некоторые сущности отвечающие за валидацию и помогающие сформировать запросы, но они больше похожи на хелперы и формы, чем на полноценный ORM или модели
BoShurik, Ninazu, вы походу противоречите друг другу...или я Вас не понимаю...
да, местами противоречат. BoShurik цитирует вам инструкции от доктрины, а Ninazu говорит "я противник ORM" и дает смесь из правильных ответов и чего-то странного, что противоречит.
Stalker_RED, BoShurik, подскажите, пожалуйста, смысл проведения миграции после создания сущностей.
Мне лично кажется, что из миграции проще создать сущность, чем наоборот.
Попробовала двумя способами:
./vendor/bin/doctrine-module orm:schema-tool:update
1.я пишу сущности-
-создаются таблицы
далее, если пишу миграции после генерации сущностей- и применяю ./vendor/bin/doctrine-module migrations:migrate- то пишут , что таблицы уже существуют...
2.пробую сначала миграции-создаются таблицы- можно создать сущности из таблиц.
А чтоб после сущностей применить миграцию, у меня не получилось.
Я не понимаю смысл миграции после создания сущностей, так как, если я добавлю сущность, могу применить
Мне лично кажется, что из миграции проще создать сущность, чем наоборот.
Вам кажется. Попробуйте таким образом добавить, к примеру, поле с типом object (Column(type="object")).
Ну и лично мне удобнее работать с маппингом через аннотации за счет автодополнения:
Я не понимаю смысл миграции после создания сущностей, так как, если я добавлю сущность, могу применить
На проде тоже так же будете выполнять? Тот же пример с object все порушит*
Подскажите, пожалуйста, каков смысл миграции после создания сущностей?
Это два разных инструмента и они друг друга не заменяют хоть немного и пересекаются на первый взгляд
На проде тоже так же будете выполнять? Тот же пример с object все порушит*
На проде никогда с фреймфорками не работала, поэтому не знаю. С Вами хочу посоветоваться...
Итак, алгоритм действии, на мой взгляд. Подправьте меня, пожалуйста, если не права, так как для меня это важно:
1. первый раз создаю сущность (таблиц нет в бд)- выполняю код:
3. Таблицы в бд появились, а дальше что надо сделать-миграцию, зачем понятия не имею- в бд таблицы появились: ./vendor/bin/doctrine-module migrations:generate-заполняем класс миграции вручную... ./vendor/bin/doctrine-module migrations:migrate-мигрируем в ту же бд- обычно ошибка, что в бд таблицы существуют.
4. Гитом с тестового сервера запушу на продакшен.
5. Выполняю на продакшене:
Итог, я пишу и сущность и миграции, те получается, что я одно и то же пишу 2 раза, а если, допустим я пишу правильно сущность, а миграцию неверно-ошибусь, или наоборот.
1. Создаем сущность
2. Выполняем команду ./vendor/bin/doctrine-module migrations:diff
у вас создается миграция с запросами, которые соответствуют маппингу вашей сущности, при необходимости можно туда что-то добавить (например, добавляете поле и надо проинициализировать его начальное значение)
3. Выполняем команду ./vendor/bin/doctrine-module migrations:migrate
ваша миграция применяется
4. Изменяем сущность
5. Выполняем команду ./vendor/bin/doctrine-module migrations:diff
у вас создается миграция с запросами, которые соответствуют изменениям в вашей сущности
6. Выполняем команду ./vendor/bin/doctrine-module migrations:migrate
ваша миграция применяется
7. Деплоите на прод
8. Выполняете команду ./vendor/bin/doctrine-module migrations:migrate
все ваши миграции применяются
Комадны orm:schema-tool:* не нужны, их заменяют миграции
То есть по вашему, надо генерировать доктрину сначала,-
создадутся таблицы на основе сущностей, а потом, если я создам миграции, таблицы в бд появятся,- уже миграции не катят, так как таблица post, к примеру, была уже создана уже в доктрине?
Извините, я не понимаю... Подскажите, плииз.
-создаются таблицы
далее, если пишу миграции после генерации сущностей- и применяю ./vendor/bin/doctrine-module migrations:migrate- то пишут , что таблицы уже существуют...
2.пробую сначала миграции-создаются таблицы- можно создать сущности из таблиц.
А чтоб после сущностей применить миграцию, у меня не получилось.
Я не понимаю смысл миграции после создания сущностей, так как, если я добавлю сущность, могу применить
Простой
