Feature request: Support @map and @@map for mapping column and table names

[tinacious]

First off, amazing library, thank you!

Prisma allows you to map column names, for example, if you wanted to stick to JavaScript naming conventions (as camelCase) in the code, and database naming conventions in the database (as snake_case), it adds @map("my_column_name").

It also has a @@map("table_name") for the table name should you not want to use the default PascalCase naming convention in the database.

For example, here is an example schema:

model PrismaUml {
  isAwesome  Boolean  @default(true) @map("is_awesome")

  @@map(name: "prisma_uml")
}

The Plant UML that gets generated uses the field isAwesome but it would be great if it could use the database field is_awesome, either by default or as a configuration option.

Thanks again for this great tool! Very quick and easy to get going with.

[emyann]

@tinacious Thank you for your feedback! It definitely makes sense to support this, I'll carve out some time to work on this feature, I'll let you know whenever it is released

It is worth mentioning though that the attributes @@map and @map does not rename the fields in the database, but rather in the Prisma client https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference#remarks-15, so the ERD will be closer to the Prisma Client than the database.

[tinacious]

@emyann thanks for the response and your openness to supporting this feature.

I see the part of the documentation you are pointing to, and I can see how it may sound confusing. Right below the part you indicated, there's further explanation.

Here is a sample schema that is probably more appropriate given that it's resource-oriented that you can try using if you haven't tried to use the mappings yourself:

 model Puppy {
   id Int @id @default(autoincrement())
   isCute Boolean @default(true) @map("is_cute")
 
   @@map("puppies")
 }

This creates a table puppies with a column is_cute:

Perhaps the part in the docs that you indicate says it does not rename the table is in the event the table has already been created. When the table is created initially, I assure you the name I indicate in @@map is respected, and the column name as indicated by @map is also respected. They are created as I expect.

With the sample puppies schema, isCute will be what I can use to create and query while is_cute will be the column name.

As per the docs, if omitted, the table and column names are created verbatim, resulting in a PascalCase table and camelCase columns:

So far all my tables have been single words, I have not tested what the client looks like for models that contain multiple words, i.e. I'm not sure how it translates the PascalCase model and what the result would be in the generated client if it would be prismaUml or prisma_uml or prismauml, but I can confirm that the table in the database would be as I indicate in @@map.

Now, if you mentioned that part of the docs because your plugin uses the Prisma client to infer the names rather than the database columns directly or the schema file (which would have both, I assume), that is understandable, but I assure you the columns and tables are named as indicated by the mappings.

It would be great to be able to configure a choice, e.g.:

• I choose to use the client names, i.e. it will use Puppy (existing functionality)
• I choose to use the client column name, i.e. it will use isCute (existing functionality)
• I choose to use the database names, i.e. puppies (requested functionality)
• I choose to use the column name is_cute (requested functionality)

In an organization that uses micro-services and may have these micro-services written in different languages (with different naming conventions, e.g. a mix of Ruby and JavaScript services), if it can be expected that they all follow the naming conventions of their databases, it would be great if the UML diagrams that were generated could optionally match these too.

Let me know if you need anymore information. Thanks again for this plugin.

[emyann]

I understand better thanks! I've never tried myself @@map and @map attributes, thanks for the thorough explanation and it makes sense to support them as a configuration!