prisma
Support `@writable(false)` or `@readonly`
To disable writing to a field, so you could never explicitly override the default
model User {
id String @id @default(autoincrement()) @writable(false)
}
This will affect Prisma Client client generation, so you couldn't pass a value into the id field.
Thanks for writing this up. So far I was mostly thinking of the concept and syntax rather as a subfeature of @default like so:
model User {
id String @id @default(autoincrement(), writeable: false)
}
What's the motivation for this?
I feel like even if you want to have readonly IDs in your application, it's very likely that you will have to set fixed IDs in your unit tests, forcing you to remove the readonly tag again.
One motivation for this could be to use @readonly on View fields before full support for Views is implemented
Another use case for something like this would be a column that is set via a database trigger that should not be written to directly. I like the idea of a @readonly attribute over making this a subfeature of @default because you could have a field you want to mark as read-only that does not have a default value.
Another case is createdAt and updatedAt fields:
model User {
id Int @id @default(autoincrement())
email String @unique
password String
createdAt DateTime @default(now()) @readonly
updatedAt DateTime @updatedAt @readonly
}
I opened up a new issue before finding this one
It contains a detailed description of a scenario where this would be useful, both for the developer experience via intellisense and to protect fields you do not want the queries to be able to set by themselves.
This intellisense diff mock is an example of how my usecase could benefit:
Current
With readonly fields
Would be a greatly improved developer experience in my opinion 😄
can a Prisma team member (paging @janpio ) give us an update regarding prioritization/roadmap? This is pretty basic functionality IMO, and I struggle to imagine a convincing argument for pushing this concern outside of Prisma. I know there's quite the backlog of open issues, but this one has been open and active for over 3 years.
What I can imagine as a deterring force is that presenting different interfaces in read/write contexts may be a significant undertaking, but IMO it's worthwhile considering most users are going to have to bolt this on top of prisma's generated interfaces for auth reasons if nothing else, and an integrated solution would be a far better developer experience and result in safer application code.
No, we only communicate our priorities via our roadmap on https://pris.ly/roadmap and do not give further ETAs, except sometimes via activity in issues that we are actively looking into. I know this can be frustrating, but there is no other scalable way to handle this.
Many of the other issues have been open for similar amounts of time, or have received a lot more feedback from users, so we are prioritizing those. At the same time, this is obviously on one of our "obvious additions to Prisma" lists and hence being looked at as soon as we have the capacity to do so.
Hello there, do we have any new about this feature ? Is it actually planned or is it still in consideration for a later version ?
I m actually covering a case where prisma generated type can actually prevent the use of DTOs (validation object), the one exception come when facing a update, as prisma do not provide a type for allowed field to be updated
This new @readonly tag would also help to cover this case
If it can help :)
waiting for this feature! mainly to get updated types for the update method of the Prisma client
any updates?
Don't wait! And switch to something else ;)
Lol nice call @jycouet, what are you using instead to achieve readonly fields?
I switched all my projects to https://remult.dev 😊 (much more than an ORM, and the ORM part is crazy good in typescript DSL directly!)
There, a field can be a serverExpression or even better a sqlExpression 🤯 !!!
DM me if you have questions
My use case would be: I want to denormalize a value across two related tables. I don't expect the value to ever change, I expect it to always be the same in both places. I want to make sure I never try to update the value. I can add check constraint that checks the foreign table but some app-level enforcement would be nice.
