Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Prisma Client] Duplicate identifier with models "X" and "XClient" #2539

Closed
dodas opened this issue May 24, 2020 · 9 comments · Fixed by #2589
Closed

[Prisma Client] Duplicate identifier with models "X" and "XClient" #2539

dodas opened this issue May 24, 2020 · 9 comments · Fixed by #2589
Assignees
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug.
Milestone

Comments

@dodas
Copy link

dodas commented May 24, 2020

Consider following datamodel:

model Company {
   ...
}

model CompanyClient {
   ...
}

Prisma seem to generate class for each model, with Client appended to its name:

// this is corresponding to model "Company"
export declare class CompanyClient<T> implements Promise<T> {
  ...
}

//  this is corresponding to model "CompanyClient"
export declare class CompanyClientClient<T> implements Promise<T> {
  ...
}

..but it also generates type for each model, without appending anything to its name:

export type Company = {
   ...
} 

export type CompanyClient = {
   ...
} 

This leads to typescript error, as type CompanyClient is clashing with class CompanyClient:

Duplicate identifier 'CompanyClient'. ts(2300)

Naming convention for "Client" classes should be altered, probably..


Prisma CLI / client version: 2.0.0-beta.5

@pantharshit00 pantharshit00 added bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug. process/candidate labels May 24, 2020
@pantharshit00
Copy link
Contributor

I can confirm this bug. Thanks for reporting!

I also think we not add this case to the deny list as this naming pattern seems a bit common.

@Jolg42
Copy link
Member

Jolg42 commented May 26, 2020

It looks like it is already in the denylist. I will double check.

@Jolg42
Copy link
Member

Jolg42 commented May 28, 2020

Thank you for the issue, the "denylist" is now applied to model names as well with tests.

You probably want to rename your models to avoid a conflict here, one solution could be to use @@map:
https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/configuring-the-prisma-client-api#using-map-and-map-to-rename-fields-and-models-in-the-prisma-client-api

@dodas
Copy link
Author

dodas commented May 28, 2020

Does that mean that issue is fixed and I can keep current model names after eventual prisma release?
Thanks!

@Jolg42
Copy link
Member

Jolg42 commented May 28, 2020

@dodas So no it means that out internal list of reserved word just got updated and it will error properly now if you retry with the latest alpha.

So you will need to change the names of your models. And if you already have these models in your database you could use @@map to keep them and only change the names for the Prisma Client / Schema.

@dodas
Copy link
Author

dodas commented May 28, 2020

That's unfortunate solution...
I think that naming models ,,SomethingClient" can be quite common and having to rename model that corresponds to business domain is not nice thing to do.
Couldn't the ,,Client" classes be named differently instead? Perhaps in a way that they could never clash with data model names?
Or maybe they can be defined in different file and prevent duplicate identifiers that way?

@Jolg42
Copy link
Member

Jolg42 commented May 28, 2020

I understand the problem here and I'm also in favor of finding a better solution 👍
The best would be to open an issue, could you do that?

@pantharshit00
Copy link
Contributor

I propose prefixing our implementation with internal. I don't know if this will be a breaking change or not:
${name}InternalClient

Generally we should prefix out implementation. What are your thoughts @Jolg42 ?

@pantharshit00
Copy link
Contributor

I opened: prisma/prisma-client-js#707

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants