Should the initial migration for an existing schema be different than the output of a mysqldump? mysqldump:

PRIMARY KEY (`id`),
  UNIQUE KEY `id_UNIQUE` (`id`),
  UNIQUE KEY `locationId` (`locationId`),
  KEY `userId` (`userId`),

  CONSTRAINT `Item_ibfk_1` FOREIGN KEY (`userId`) REFERENCES `User` (`id`),
  CONSTRAINT `Item_ibfk_2` FOREIGN KEY (`locationId`) REFERENCES `Location` (`id`)

prisma migrate:

PRIMARY KEY (`id`)  
  UNIQUE INDEX `Item.locationId_unique`(`locationId`),
  INDEX `userId`(`userId`),

  ALTER TABLE `Item` ADD FOREIGN KEY (`userId`) REFERENCES `User`(`id`) ON DELETE SET NULL ON UPDATE CASCADE;
  ALTER TABLE `Item` ADD FOREIGN KEY (`locationId`) REFERENCES `Location`(`id`) ON DELETE SET NULL ON UPDATE CASCADE;

From above you should see that migrate got two things wrong:

1- missing: 
UNIQUE KEY `id_UNIQUE` (`id`)

2- wrong name, should have been `locationId`
UNIQUE INDEX `Item.locationId_unique`(`locationId`)

I checked the generated migration line by line. All tables are missing

UNIQUE KEY id_UNIQUE (id)

, in addition to some tables having inconsistent index/key names; sometimes it's prepended by the table name, others isn't. Also, would using these newly generated prisma index names cause any problems on production? (when base-lining for example) Should I accept the initial migration and apply it as is, then run and edit a second migration to rename these indexes and missing constraints?