Preview feature feedback: Referential Actions (`referentialActions`)
janpio opened this issue · comments
Please share your feedback about the referentialActions functionality released in v2.26.0 in this issue.
- If you encounter a bug, please open a bug report in this repo.
- If the feature is working well for you, please share this in a comment below or leave a 👍 on this issue.
If you have any questions, don't hesitate to ask them in the #prisma-client channel in the Prisma Slack.
Known Limitations
VSCode extension/language tool
The new cascade feature works very well for me now. Upgrading was very simple and I could remove some of the hacks around cascade not working properly (I previously had a transaction that first deleted all related elements and then deleted the item itself).
Only thing that’s missing is as far as I can see the documentation. It’s documented well in the release, but the docs still claim that cascade is impossible.
Documentation PR is in the works and will be merged in the coming days. It's a complex topic, but all the necessary information should be in the release notes for now - and we will expand on that as soon as possible.
Thanks for the positive feedback @FlorianWendelborn - and thanks for trying it out so quickly.
Thanks for your effort and work and for delivering this greater feature. 👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽👏🏽
Hey I just upgraded to 2.26.0 deleted node_modules. But the Prisma Language Server is keeping saying to me:
The preview feature "referentialActions" is not known. Expected one of: microsoftSqlServer, orderByRelation, nApi, selectRelationCount, orderByAggregateGroup, filterJson
@SvenC56 The language server is independent and needs to be updated via the Prisma extension you are using, probably VSCode. Make sure you are running 2.26.0 of the extension as well (usually happens automatically, but sometimes doesn't).
@janpio thank you for your fast feedback. I keep getting this message. I reinstalled the Prisma VSCode Plugin and restarted VSCode.
This is the Output from the language server:
[Info - 10:22:44] Default version of Prisma binary 'prisma-fmt': 9b816b3aa13cc270074f172f30d6eda8a8ce867d
[Info - 10:22:44] Extension name @prisma/language-server with version 2.26.0
[Info - 10:22:44] Prisma CLI version: 2.26.0
Using binary path from Prisma Language Server configuration.
[Info - 10:22:46] Local prisma-fmt path: /home/ciesloks/Dev/prisma-fmt/prisma-fmt
Binary test successful.
Using binary path from Prisma Language Server configuration.
That version looks correct. Can you open an issue over at https://github.com/prisma/language-tools/issues please? Then we can take a look at it and ask related questions.
Amazing feature. Just tried it for one little project in production and it works like a charm. I overuse cascade deletes, and for now it seems stable to me :)
@SvenC56 I think you should try uninstall prisma from your devDependencies, as well as your @prisma/client from your dependencies, then uninstall the extension from VScode (make sure you restart Vscode as well). Then install all again and try it, I did exactly that and worked to me.
@janpio that is an amazing waiting feature. Thank you really much.
I'm just wondering, 1) if you're adding this feature to your relation fields, why isn't being reflected in the SQL files generated by the migration command? and in the other hand, 2) if you are using introspection feature to get accesses to an existent database which already supports on delete configurations, will the introspection get those details (or some of them) in the generated prisma schema?
- if you're adding this feature to your relation fields, why isn't being reflected in the SQL files generated by the migration command?
That should be the case with the preview feature enabled in 2.26.0. If not, that is a bug.
- if you are using introspection feature to get accesses to an existent database which already supports on delete configurations, will the introspection get those details (or some of them) in the generated prisma schema?
Yes, all this should be fully picked up with the preview feature enabled in 2.26.0.
It worked! Great!!
- Referential actions can not be specified on relations in implicit many-to-many relations. This limitation can be worked around by switching to explicit many-to-many relations and specifying the referential actions on the relations in the relations table.
How can I migrate existing implicit many-to-many to explicit many-to-many without losing any data to be able to use this workaround?
@PabloSzx I don't know if there is a better solution, but one approach would be renaming the table (it should be called something like _ModelAToModelB) to something else, then using db pull / introspect and the table would show up in your prisma schema.
After upgrading to 2.27.0 I also started using the referential actions. In my e2e tests i delete all entities based on a tenantId (multi-tenant setup)
The schema basically looks like this
model Connector {
tenantId String @db.VarChar
id String @db.VarChar
evseUid String? @db.VarChar
evse ChargePoint? @relation(fields: [tenantId, evseUid], references: [tenantId, uid], onDelete: Cascade)
@@id([tenantId, id])
}
model ChargePoint {
tenantId String @db.VarChar
uid String @db.VarChar
location_id String? @db.VarChar
location Location? @relation(fields: [tenantId, location_id], references: [tenantId, id], onDelete: Cascade)
connectors Connector[]
@@id([tenantId, uid])
}
model Location {
tenantId String @db.VarChar
id String @db.VarChar
evses ChargePoint[]
groups LocationsOnLocationGroup[]
tenant Tenant @relation(fields: [tenantId], references: [id], onDelete: Cascade)
@@id([tenantId, id])
}
model LocationGroup {
tenantId String @db.VarChar
id String @default(uuid()) @db.Uuid
name String @db.VarChar
locations LocationsOnLocationGroup[]
tenant Tenant @relation(fields: [tenantId], references: [id], onDelete: Cascade)
@@id([tenantId, id])
}
model LocationsOnLocationGroup {
tenantId String @db.VarChar
location Location @relation(fields: [tenantId, locationId], references: [tenantId, id], onDelete: Cascade)
locationId String @db.VarChar
locationGroup LocationGroup @relation(fields: [tenantId, locationGroupId], references: [tenantId, id], onDelete: Cascade)
locationGroupId String @db.Uuid
@@id([tenantId, locationId, locationGroupId])
}
model Tenant {
id String @id @db.VarChar
locations Location[]
LocationGroup LocationGroup[]
}
Now when using prisma.locations.deleteMany({where: {tenantId: "myTenantName"}}) I get:
Null constraint violation on the fields: (tenantId)
Weird thing is I can't reproduce the issue in a new project even when first using 2.25.0 and then switching to 2.27.0 (same I did in my original project).
Any ideas how to debug this otherwiese?
Optimally open a new issue so we can start a discussion about this @tlindener.
(Approach: Compare SQL schema of the two databases, probably your old schema is not up to date with the Prisma Schema yet and creating a new project somehow you do things differently to avoid that.)
Seems like I looked at the wrong place when creating a smaller project. I created a ticket with an approach to reproduce the issue: #8264
Closing this now that this has been released to General Availability in the 3.0.1 release