Retain @map annotations for fields with distinct DB column names about prisma-case-format HOT 6 CLOSED

I get where you're coming from, and I can genuinely see the perspective from which this makes sense and is reasonable. The only hangups I have are:

• The repository is prisma-case-format and not prisma-mapping-linter, although frankly, maybe it should change, if this is what the users are asking for.
• Personally, I don't totally buy the narrative that schema.prisma's need a linter, but maybe there are dev workflows out there in which it genuinely is possible to sneak a field name change past peer review.
• If we're not using the 'disable' semantic, it feels like we're essentially signing-in-triplicate: "And so fullName, son of "first_name_last_name", first of his name, shall forever henceforth be known as fullName, for so twas ordained not only in schema.prisma but also in the .prisma-case-format, and he whosoever should try to change it shall be put to death by the CI/CD job in a public square of his choosing..." 😛 like, to my mind, that was the point of the schema.prisma: to be the source of truth. Although, I know that prisma also supports an introspect-oriented database-first approach where migration scripts are the first source of truth and the schema is a knock-on file.

In the end, I think you're probably right, I just need to mull it over.

from prisma-case-format.

What's your setup?

from prisma-case-format.

I may have miscalculated the next auth default schema

from prisma-case-format.

So, on https://authjs.dev/reference/adapter/prisma at least the latest version shows that expires is just a DateTime with no map.

however, you should be able to specify the whole .prisma-case-format file right now (as discussed in our previous thread), but then for the VerificationToken model, you can do

override:
  ...
  VerificationToken:
    ...
    expires: 'disable'

I'll work on making it so this works in tandem with --uses-next-auth so that you don't have to specify everything. Also I spotted some bugs that I need to squash before I merge this all and graduate it from beta.

Thanks for pointing these problems out.

from prisma-case-format.

Right, the @map isn't required by Auth.js, but that's needed in our case because the DB schema follows a strict convention for date-time columns (they all end with an _at suffix). We have a few other situations where the fields required by Auth.js/Next-Auth map to a DB column where the name differs from the field name (not only in case) and also require a @map.

override:
  ...
  VerificationToken:
    ...
    expires: 'disable'

Thanks, you're right that's an option I didn't consider.

I'm still not sure if it is a good default to remove or overwrite existing @map for cases where both names differ (by "existing maps" I mean the ones that aren't managed by prisma-case-format). If I take the following example:

model MyModel {
  fullName String @map("first_name_last_name")
}

Here we may have a situation with a DB with a pre-existing column named first_name_last_name that cannot be changed due to reasons (e.g. other systems already depend on it), but we would prefer to present it as a fullName field for the generated Prisma client. Ideally prisma-case-format could still ensure the field name is camelCase and the column name is snake_case, but wouldn't remove or replace the @map. Or maybe in this situation it may be even safer to completely ignore the @map case? Not 100% sure.

from prisma-case-format.

I've added the ability for this in the .prisma-case-format file in v2.2.0.

override:
  MyModel:
    field:
      fullName: mapField=!first_name_last_name

See docs for more detail

from prisma-case-format.