Fullstack TypeScript toolkit that enhances Prisma ORM with flexible Authorization layer for RBAC/ABAC/PBAC/ReBAC, offering auto-generated type-safe APIs and frontend hooks.
Description and expected behavior
When a polymorphic model inherits a reference, zenstack doesn't recognize the inverse relationship correctly.
In the following contrived schema, which generates correctly: abstract model B defines a reference to A; polymorphic model C inherits B; and A defines the inverse relation to C.
// no errors in this schema
model A {
id Int @id
cs C[]
}
abstract model B {
a A @relation(fields: [aId], references: [id])
aId Int
}
model C extends B {
id Int @id
type String
@@delegate(type)
}
However, once we define the following subclass on C, zenstack raises an error on attribute B.a: The relation field "a" on model "D" is missing an opposite relation field on model "A"zmodel(miss-opposite-relation)
// adding this causes an error
model D extends C {
}
As a workaround, we can move the B.a reference to model C, and the error goes away:
// this is an equivalent schema that causes no errors
model A {
id Int @id
cs C[]
}
abstract model B {
}
model C extends B {
id Int @id
a A @relation(fields: [aId], references: [id])
aId Int
type String
@@delegate(type)
}
model D extends C {
}
This isn't a big problem, but it does remove some expressiveness in less contrived schemas. (I stumbled on this when trying to define a real schema, not the contrived example.)
Environment (please complete the following information):
Description and expected behavior When a polymorphic model inherits a reference, zenstack doesn't recognize the inverse relationship correctly.
In the following contrived schema, which generates correctly: abstract model B defines a reference to A; polymorphic model C inherits B; and A defines the inverse relation to C.
However, once we define the following subclass on C, zenstack raises an error on attribute B.a:
The relation field "a" on model "D" is missing an opposite relation field on model "A"zmodel(miss-opposite-relation)
As a workaround, we can move the B.a reference to model C, and the error goes away:
This isn't a big problem, but it does remove some expressiveness in less contrived schemas. (I stumbled on this when trying to define a real schema, not the contrived example.)
Environment (please complete the following information):