TypeORM CLI: не найдено изменений в схеме базы данных - PullRequest
Новая
       18

TypeORM CLI: не найдено изменений в схеме базы данных

2 голосов
/ 28 апреля 2020

Я занимаюсь разработкой приложения с использованием Nest JS и TypeORM. Всякий раз, когда я пытаюсь сгенерировать миграции из своих сущностей (запустив typeorm migration:generate), я получаю следующее сообщение: 

No changes in database schema were found - cannot generate a migration. To create a new empty migration use "typeorm migration:create" command

Я даже удаляю все существующие файлы миграции (из папки миграций), чтобы исключить любую возможность конфликта .

Проблема началась после того, как я изменил структуру папок модулей моего приложения на: 

src
 |- config
 |   |- database
 |       |- mysql
 |           |- cli-configuration.ts
 |- migrations
 |- module1
     |- controller
     |- entity
     |- service

Как видно, папка migrations находится прямо под src, и у каждого модуля есть entity папка, в которой находятся объекты для этого модуля. Все настройки ormconfig взяты из файла cli-configuration.ts.

В package.json файле я добавил следующее в scripts: 

{
  ...
  "scripts": {
    ...
    "typeorm": "ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js --config src/config/database/mysql/cli-configuration.ts",
    "typeorm:migrate": "npm run typeorm migration:generate -- -n",
    "typeorm:run": "npm run typeorm migration:run"
  }
}

Содержимое файла src/config/database/mysql/cli-configuration.ts: 1022 * 

import * as path from 'path';
import * as dotenv from 'dotenv';

dotenv.config({
  // Path relative to project root folder (because cli command is invoked from there)
  path: path.resolve('environment', (process.env.NODE_ENV === "production") ? ".env.production" : ".env")
});

const config = {
  type: "mysql",
  host: process.env.TYPEORM_HOST,
  port: Number(process.env.TYPEORM_PORT),
  username: process.env.TYPEORM_USERNAME,
  password: process.env.TYPEORM_PASSWORD,
  database: process.env.TYPEORM_DATABASE,
  entities: [path.resolve('src', process.env.TYPEORM_ENTITIES)],

  // We are using migrations, synchronize should be set to false.
  synchronize: false,

  // Run migrations automatically,
  // you can disable this if you prefer running migration manually.
  migrationsRun: true,
  logging: process.env.TYPEORM_LOGGING,

  // Allow both start:prod and start:dev to use migrations
  // __dirname is either dist or src folder, meaning either
  // the compiled js in prod or the ts in dev.
  migrations: [path.resolve('src', process.env.TYPEORM_MIGRATIONS)],
  cli: {
    // Location of migration should be inside src folder
    // to be compiled into dist/ folder.
    // entitiesDir: process.env.TYPEORM_ENTITIES_DIR,
    migrationsDir: path.resolve('src', process.env.TYPEORM_MIGRATIONS_DIR),
    // subscribersDir: process.env.TYPEORM_SUBSCRIBERS_DIR,
  },
  dropSchema: false
};

export = config;

Запуск console.log(config) Я получаю: 

{
  type: 'mysql',
  host: 'localhost',
  port: 3306,
  username: 'root',
  password: 'root',
  database: 'myapp',
  entities: [ '/var/www/html/myapp/src/**/*.entity{.ts,.js}' ],
  synchronize: false,
  migrationsRun: true,
  logging: 'all',
  migrations: [ '/var/www/html/myapp/src/migrations/**/*{.ts,.js}' ],
  cli: { migrationsDir: '/var/www/html/myapp/src/migrations' },
  dropSchema: false
}

Последнее, но не менее важное ... После нескольких часов работы над этой проблемой (внесение изменений в миграцию и пути к сущностям, значения в жестком коде помимо получения их из process.env, et c), я пытался выполнить yarn run typeorm schema:log (npm run также работает). Я удивился, когда увидел, что весь контент, который я ожидал найти в файле миграции, который я пытаюсь сгенерировать, был выведен на консоль. 

CREATE TABLE `permission_permission` (`id` varchar(36) NOT NULL, `name` varchar(100) NOT NULL, `code` text NOT NULL, `create_date` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), `update_date` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), `delete_date` datetime(6) NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB;
CREATE TABLE `permission_role` (`id` varchar(36) NOT NULL, `name` varchar(100) NOT NULL, `code` varchar(255) NOT NULL, `create_date` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), `update_date` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), `delete_date` datetime(6) NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB;
CREATE TABLE `user_user` (`id` varchar(36) NOT NULL, `email` varchar(255) NOT NULL, `password` varchar(255) NOT NULL, `first_name` varchar(255) NOT NULL, `last_name` varchar(255) NOT NULL, `is_active` tinyint NOT NULL DEFAULT 0, `create_date` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), `update_date` datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6), `delete_date` datetime(6) NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB;
CREATE TABLE `permission_role_permission` (`permission_id` varchar(36) NOT NULL, `role_id` varchar(36) NOT NULL, INDEX `IDX_3247040996395a5faea3c9b3a5` (`permission_id`), INDEX `IDX_7d9cfbfd027256ab08658bcf6e` (`role_id`), PRIMARY KEY (`permission_id`, `role_id`)) ENGINE=InnoDB;
CREATE TABLE `user_user_role` (`role_id` varchar(36) NOT NULL, `user_id` varchar(36) NOT NULL, INDEX `IDX_c0c2bbb31e8e8708efc6dd5a64` (`role_id`), INDEX `IDX_beb8c39c852f4d132ba44b483c` (`user_id`), PRIMARY KEY (`role_id`, `user_id`)) ENGINE=InnoDB;
ALTER TABLE `permission_role_permission` ADD CONSTRAINT `FK_3247040996395a5faea3c9b3a54` FOREIGN KEY (`permission_id`) REFERENCES `permission_role`(`id`) ON DELETE CASCADE ON UPDATE NO ACTION;
ALTER TABLE `permission_role_permission` ADD CONSTRAINT `FK_7d9cfbfd027256ab08658bcf6e1` FOREIGN KEY (`role_id`) REFERENCES `permission_permission`(`id`) ON DELETE CASCADE ON UPDATE NO ACTION;
ALTER TABLE `user_user_role` ADD CONSTRAINT `FK_c0c2bbb31e8e8708efc6dd5a64b` FOREIGN KEY (`role_id`) REFERENCES `user_user`(`id`) ON DELETE CASCADE ON UPDATE NO ACTION;
ALTER TABLE `user_user_role` ADD CONSTRAINT `FK_beb8c39c852f4d132ba44b483c0` FOREIGN KEY (`user_id`) REFERENCES `permission_role`(`id`) ON DELETE CASCADE ON UPDATE NO ACTION;

Может кто-нибудь сказать мне, почему schema:log обнаруживает изменения в моих сущностях, но migration:generate не работает?

...