TypeORM 的迁移：generate 重新生成整个数据库模式答案

【问题标题】：TypeORM's migration:generate regenerates the whole database schemaTypeORM 的迁移：generate 重新生成整个数据库模式
【发布时间】：2018-10-14 06:48:38
【问题描述】：

每次我运行 migration:generate 时，它都会创建一个重新生成整个数据库架构的迁移（而不是仅针对我的实体最近的更改进行迁移）。我使用的是最新版本的 Typeorm 0.2.7 版。

我的ormconfig.json 是：

{
  "host": "localhost",
  "logging": false,
  "port": 5432,
  "synchronize": false,
  "type": "postgres",

  "entities": ["build/server/entity/*.js"],
  "migrations": ["build/server/migration/*.js"],

  "cli": {
    "entitiesDir": "build/server/entity",
    "migrationsDir": "build/server/migration"
  },

  "username": "***",
  "password": "***",
  "database": "***"
}

当我运行typeorm migration:generate -n SomeEntityChanges 时，新的迁移文件包含为我的所有实体创建和链接表的说明，即使它们中的大多数已经在build/server/migration 中进行了相应的迁移。 p>

当我运行 typeorm migration:run 时，我可以看到没有挂起的迁移，并且覆盖现有实体的迁移已经运行（即它们在我的 migrations 表中）。

我错过了什么？ docs 表示 migration:generate 命令应该只生成包含最近更改的迁移。

【问题讨论】：

我对 postgres 也有同样的问题 :-?
@hungneox 如果您的实体中有{schema: 'public'}，请尝试删除它

标签： typeorm

【解决方案1】：

这听起来可能很愚蠢，但我遇到了同样的问题，问题是我的数据库名称。我的数据库名称是 mydbLocal，带有大写 L，但是当 typeorm 正在读取以生成新的迁移时，它会查找 mydblocal，并且由于没有具有该名称的模式，它会导致生成重新生成整个模式。这似乎是一个错误，因为在解析模式时它会寻找小写的模式，但在运行迁移时它会进入真正的模式（大写 L）。

无论如何，我解决它的方法是将我的数据库名称更改为全部小写，并将我的 ormconfig 数据库名称编辑为全部小写。

这是一个非常奇怪的情况，但这解决了我的问题。希望它也会对其他人有所帮助。

【讨论】：

【解决方案2】：

正如前面提到的答案之一，对我来说，问题确实是数据库名称的驼峰式。将数据库名称更改为全小写似乎已经解决了迁移生成问题。

但是，在我的新项目中，我注意到实体表名称覆盖似乎也具有相同的行为。奇怪的是，这对我来说在以前的项目中都不是问题。

//Previous table name causing migration file to regenerate    
@Entity({
      name: 'TempTable',
    })

//New table name which stops the regeneration   
@Entity({
      name: 'temp_table',
    })

希望这对面临同样问题的人有所帮助。

【讨论】：

我在使用 PascalCase 表名的 MySQL 上遇到了这个问题。如果我将实体装饰器@Entity('tablename' 中的表名小写，则该表被识别为存在并且不会生成CREATE TABLE，但是在此项目中将表名更改为小写不是我的选择。好痛苦。

【解决方案3】：

从我的所有 @Entity 定义中删除 {schema: 'public'} 使用 Postgresql 为我修复了它

上一个： @Entity({schema: 'public'})

工作： @Entity()

【讨论】：

在 MySQL 上遇到同样的问题，我的代码中没有 { schema: "public" }。
为什么我的解决方案对我有用
作为后续跟进，此注释出现在我面前，因为我有一个正在处理的现有数据库，并且我使用了自动代码生成器来创建实体。我不知道为什么会这样，但删除 {schema: 'public'} 就成功了。可悲的是，更改表格的大小写（如其他问题的答案中所述）超出了我的范围

【解决方案4】：

这是因为您的数据库可能是空的。 TypeOrm 计算实际代码库实体和实际数据库之间的差异，从而生成迁移。

检查您的 ormconfig.json，因为它是 typeorm CLI 读取以生成迁移的内容，它可能指向一个空数据库，从而生成迁移中的所有表。

只需在您的数据库上迁移，然后再次运行生成。

【讨论】：

我在一个干净的数据库上遇到了同样的问题，它第一次生成正确的迁移，用实体填充数据库，然后第二次生成相同的迁移。数据库绝对不是空的。

【解决方案5】：

我一直在 MySQL 上遇到这个问题，经过几个小时的修补，我终于解决了这个问题。

假设 { schema: "public" } 修复对您不起作用，以下是我必须采取的措施来清理可怕的迁移一代。

首先，确保您运行的是最新版本的 TypeORM。我被一些小版本拖垮了，仅此一项就足以给我带来无数基于索引的错误。

如果你是最新的，太好了！坏消息是：你的实体错了。我一直遇到的最大问题是我的大多数重复文件中的default 属性。据我了解，当 TypeORM 尝试将数据库默认值与定义的默认值进行比较时，Postgres 和 MySQL 返回的结果都与预期不同。

例如：对于带有 4 位小数的“十进制”类型，default: 0 在构建列时可以正常工作，但 MySQL 实际上返回 "0.0000"，这意味着无论您运行此更新多少次，默认值永远不会是文字零。 TypeORM 发现这有所不同，并希望将现有的 MySQL 默认值更改回正常的零。

此错误涵盖从 default: null 到“tinyint”布尔值在我的架构中被列为 int 的所有内容。

仔细阅读生成的输出并检查每个实体中提到的属性。通过更新到最新版本的 TypeORM 修复了其中的一些问题，但通过确保默认数据实际上与 MySQL 存储的数据匹配，我设法完全清除了近 250 个表更改。

【讨论】：

【解决方案6】：

我遇到了同样的问题，我的解决方案不是很不错，但实际上“有效”。

在整个数据库的迁移中，搜索涉及的表，过滤它们，并删除由 typeorm 生成的所有其他查询，删除后，运行迁移命令，它将起作用，创建/更改您想要的表。

它不可扩展，但请记住，here 他们指定在迁移之前只更改几个表。 The rule of thumb is to generate a migration after each entity change.

【讨论】：

【解决方案7】：

第一注意小写还是大写

第二如果您使用大写名称，请将其放在“”

第三如果您使用架构，请将其添加到 ormconfig 喜欢：

"schema": "public",

祝你好运

【讨论】：

【解决方案8】：

在我的情况下，大约四次迁移后，新迁移由旧更改组成。搜索网络，从这里检查/尝试其他答案。在我的情况下，唯一有帮助的就是删除项目，再次克隆它，再次设置它（添加 .env，运行 npm install），运行当前迁移，生成新的迁移文件，其中只有新的更改为预期的。当然这并不能说明根本原因，但在那之后我可以继续工作而不会出现问题。

rm -rf project
git clone project
cd project
npm ci
ts-node ./node_modules/typeorm/cli migration:run

这两个 cmets (1, 2) 让我尝试了这个。

【讨论】：

【解决方案9】：

您应该使用migration:create 而不是migration:generate。我推荐的是，在你的package.json：

{
  ...
  scripts: {
    "migration:create": "NODE_ENV=local npm run typeorm -- migration:create -n",
    "typeorm": "ts-node -r tsconfig-paths/register ./node_modules/.bin/typeorm"
  }
}

然后你就可以运行了：

$ npm run migration:create NameOfYourMigration

成功创建迁移。

【讨论】：

但相比 :generate 迁移文件是空的。如何在不添加所有其他内容的情况下自动添加更改。
这不是问题