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

Support custom field names without @map #964

Open
D3f0 opened this issue May 23, 2024 · 1 comment
Open

Support custom field names without @map #964

D3f0 opened this issue May 23, 2024 · 1 comment
Labels

Comments

@D3f0
Copy link

D3f0 commented May 23, 2024

Problem

Currently, using a schema like the one bellow will trigger the generator's default dmmf validation preventing using the name schema.

datasource client {
    provider = "sqlite"
    url = "file:db.sqlite"
}
generator client {
  provider             = "prisma-client-py"
  interface            = "asyncio"
  recursive_type_depth = 5
}

model Entity {
  id    Int     @id @default(autoincrement())
  email String  @unique
  schema  String?
}

When running poetry run prisma push

Suggested solution

Create fields with {reserver_name}_ for example, schema_ for the above case, and use Pyndantic aliases.

Alternatives

Create a custom generator.py, but run into problems:

  • Creating the dmmf needs the generator's class _on_request to be overridden (assumed to be part of the internal API)
  • To enable accept the {reserver_name}_ to {real column} looks like the substitution could go in the class QueryBuilder.get_default_fields, but then again, seems to be part of the internal API, not meant for override.

Additional context

In my use case, the schema file is coming from a TypeScript project and I want to keep compatibility with it without changing the file.

@RobertCraigie RobertCraigie changed the title Allow to use Pydantic aliases for column names that shadow BaseModel attributes Support custom field names without @map Aug 4, 2024
@RobertCraigie
Copy link
Owner

If you weren't aware, this is achievable at the client level, without needing to perform db migrations with @map but this would mean you need to update your TypeScript project to use that field name as well.

I would not want automatically rename the field but supporting something like this would likely work quite well

model Entity {
  id    Int     @id @default(autoincrement())
  email String  @unique
  /// @Python(field_name: "schema_field")
  schema  String?
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants