Invalid datamodel produced for column names differing only by numeric prefix

Bug description

If the SQL scheme has a table with multiple column names that are the same expect for their numeric prefix, an invalid datamodel is produced when pulling the db.

I think this is issue mainly affects people trying to integrate Prisma into an existing project.

example SQL schema

CREATE TABLE users (
	id INT NOT NULL AUTO_INCREMENT,
	PRIMARY KEY (id)
);

CREATE TABLE user_contact_preferences (
	id INT NOT NULL AUTO_INCREMENT,
	user_id INT NOT NULL,
	1_preference VARCHAR(255),
	2_preference VARCHAR(255),
	PRIMARY KEY (id),
	FOREIGN KEY (user_id) REFERENCES users(id)
);

How to reproduce

1. Create the SQL tables

CREATE TABLE users (
	id INT NOT NULL AUTO_INCREMENT,
	PRIMARY KEY (id)
);

CREATE TABLE user_contact_preferences (
	id INT NOT NULL AUTO_INCREMENT,
	user_id INT NOT NULL,
	1_preference VARCHAR(255),
	2_preference VARCHAR(255),
	PRIMARY KEY (id),
	FOREIGN KEY (user_id) REFERENCES users(id)
);

1. Pull the DB schema

npx prisma db pull

1. Validate the datamodel/schama

prisma validate

1. Observe failure to validate

Error: Schema parsing
error: Field "preference" is already defined on model "user_contact_preferences".
  -->  schema.prisma:21
   |
20 |   preference String? @map("1_preference") @db.VarChar(255)
21 |   preference String? @map("2_preference") @db.VarChar(255)
   |

Validation Error Count: 1

Expected behavior

Prisma should produce a valid schema

Prisma information

For reference the schema that is produced is:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

model user_contact_preferences {
  id         Int     @id @default(autoincrement())
  user_id    Int
  preference String? @map("1_preference") @db.VarChar(255)
  preference String? @map("2_preference") @db.VarChar(255)
  users      users   @relation(fields: [user_id], references: [id], onDelete: NoAction, onUpdate: NoAction, map: "user_contact_preferences_ibfk_1")

  @@index([user_id], map: "user_id")
}

model users {
  id                       Int                        @id @default(autoincrement())
  user_contact_preferences user_contact_preferences[]
}

Environment & setup

• OS: macos
• Database: mysql 8
• Node.js version: v16.13.0

Prisma Version

prisma                  : 3.6.0
@prisma/client          : 3.6.0
Current platform        : darwin
Query Engine (Node-API) : libquery-engine dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : dc520b92b1ebb2d28dc3161f9f82e875bd35d727
Studio                  : 0.440.0

[janpio]

All good, this started a nice discussion internally and even showed us a few places where having this would unblock our own CI systems and Confidence tooling 😆

… automatically rename the field from 1_preference to preference_1

Just putting the offending characters at the end of the string is a very interesting suggestion.

maybe alternatively it would just comment the fields out like it does for invalid models?

We considered that, but decided against it as we can technically support these fields - we can just not come up with a good name for them.

As a conclusion to this issue here I created https://github.com/prisma/prisma/issues/10531 - which would at least make this more visible to you, the user (Honestly, I thought we already had that and thought this was acceptable because of it - without the warning I totally understand how this is confusing to you.)

[kyle-mccarthy]

Sorry automatically was a poor choice of words. I meant would it be possible to expose it as an opt-in configuration option, which when enabled would automatically rename the field from 1_preference to preference_1.

I realize that probably isn’t as simple as it sounds, maybe alternatively it would just comment the fields out like it does for invalid models?

However, since it doesn’t sound like it is a bug and the functionality is intended, I’ll close this issue. Thank you for the clarification!