ENTITY_NAME в пути — placeholder каталога вашей сущности, например product для Product; EntityName — её тип в коде. Подставьте фактические имена своего проекта. Примеры Article ниже показывают отдельную сущность, а не обязательный модуль любого приложения.
Сгенерированный код можно заново получить из модели. Твои custom-файлы нужно сохранить, а историю SQL — продолжить новыми миграциями. Эти правила заданы в плане генерации: одного имени папки недостаточно, чтобы понять, как будет обновляться файл.
| Категория | Примеры | При следующем Generate |
|---|---|---|
| Сгенерированный код и контракты | domain/ENTITY_NAME.go, app/ENTITY_NAME/, HTTP/SQL-адаптеры, React generated, OpenAPI |
Обновляются из модели. Ручные изменения в отслеживаемом файле могут вызвать конфликт. Force overwrite перезаписывает соответствующий файл — сначала проверь, какие правки будут потеряны. |
| Custom-файлы | backend/internal/custom/, features/ENTITY_NAME/custom/, admin/custom/vite.ts |
По правилу seed_if_missing стартовый файл создаётся только при отсутствии. Существующий файл сохраняется и автоматически не адаптируется под новую модель. |
| SQL-миграции генератора | backend/migrations/*.sql |
Изменения схемы добавляются новыми миграциями. Прежняя история не генерируется заново как обычный исходник. |
| Custom-миграции | backend/migrations/custom/ |
Ты пишешь SQL и регистрируешь файл в backend/migrations/manifest.json. Он включается в общую последовательность. Применённый файл нельзя переписывать: для следующего изменения создай новую миграцию. |
Generate меняет файлы проекта. БД изменяется отдельно, при выполнении миграций. Действие Discard ungenerated changes возвращает только manifest к последнему успешному Generate; данные и запущенный релиз оно не откатывает. При явном удалении сущности её custom-файлы могут быть перенесены в архив после отдельного подтверждения.