Для смены имени используйте Rename. Он сохраняет связь поля с существующими данными. Удаление старого поля и добавление нового такой связи не сохраняет и подходит для другой задачи.
Переименование сохранённого поля
Сначала посмотрите результат:
admingen-cli --path ./docs-demo field rename Article title --to heading --preview
Из ответа скопируйте ревизии manifest и lock. Затем подтвердите именно этот вариант:
admingen-cli --path ./docs-demo field rename Article title --to heading --confirm \
--expected-manifest-revision '<ревизия manifest из preview>' \
--expected-lock-revision '<ревизия lock из preview>'
Вместо текста в угловых скобках подставьте реальные токены из preview. Оба режима возвращают JSON с ревизиями даже при text-выводе. Если модель успели изменить, повторите preview: старые токены больше не подходят.
| Флаг | Назначение |
|---|---|
--to NAME |
Новое техническое имя; обязателен. |
--preview |
Только расчёт последствий. |
--confirm |
Подтверждение изменения модели; взаимоисключающий с preview. |
--expected-manifest-revision |
Версия manifest, рассмотренная пользователем. |
--expected-lock-revision |
Версия lock, рассмотренная пользователем. |
Подтверждение меняет модель. После него выполните plan, dry-run, Generate и необходимые миграции. Preview также покажет, поддерживается ли конкретное переименование. Обычный field update --new-name не заменяет Rename. Полная форма entity field rename равнозначна field rename.
Удаление обычного поля
admingen-cli --path ./docs-demo field delete Article obsoleteNote --confirm-data-loss
Для уже выпущенного столбца флаг подтверждает потерю данных при последующем применении DROP-миграции. Сохранение манифеста само по себе строки БД не удаляет.
Защищённые идентификаторы и зависимые поля нельзя произвольно заменить этим способом. Если значения нужно сохранить, сначала подготовьте их перенос собственной миграцией.
После первой успешной генерации тип хранения нельзя поменять ни --type, ни ручной правкой манифеста. Создайте новое поле, перенесите значения явным SQL и только после этого планируйте удаление старого.
Удаление сущности
admingen-cli --path ./docs-demo entity delete OldArticle --storage retain --archive-custom
| Флаг | Действие |
|---|---|
--storage retain |
Снять сущность с генерации, сохранить физические данные. |
--storage drop |
Запланировать удаление хранения; нужен --confirm-data-loss. |
--archive-custom |
Архивировать выведенные из использования custom-исходники вне корней компиляции. |
--confirm-data-loss |
Явно подтвердить уничтожение данных при применении миграции. |
Для ранее сгенерированной сущности storage нужно выбрать явно. Зависимости и связи могут препятствовать удалению. Сначала исправьте модель; ручное удаление файлов не заменяет эту проверку.
Архив custom сохраняет исходники, а не данные БД. Виртуальную проекцию удаляйте через projection delete NAME: собственной таблицы у неё нет.
После каждого изменения просмотрите plan и diff. Дополнительные инструкции — собственные миграции и custom-код.