Title
m

Matheus Assis

08/14/2020, 2:06 PM
Is there a way to have a "computed"/"fake" field in schema.prisma while not having the column in the database?
r

Ryan

08/14/2020, 2:09 PM
Hey @Matheus Assis 👋 Currently it’s not possible in Prisma, but we have a spec https://github.com/prisma/specs/issues/269
As a workaround, you would need to use those computed fields in the business logic itself for the time being.
m

Matheus Assis

08/14/2020, 2:17 PM
Hi ryan! Thansk for the answer! In my case the fix would need to exist in schema.prisma. It's related to this issue here: https://github.com/graphql-nexus/nexus-plugin-prisma/issues/648 You'll see that to fix the issue we have to add a dummy field but then i get the error that this field also needs to be a column in the db, and we don't want to have a "hacky" dummy column in our db. We'll probably use indirect many-to-many relationships but we also don't like naming our columns "a" or "b". But well, we got to choose one thing to work with 🤷 . Thanks again!
r

Ryan

08/14/2020, 2:22 PM
Could you explain your use case? Also would a computed field like this help?
m

Matheus Assis

08/14/2020, 2:29 PM
My use case is: In an explicit many-to-many relationship. If the many -to-many model declared in schema.prisma does not have any field besides only the primary key and relations. The nexus binding generation won't generate input types correctly due to a bug. A fix to that bug is to add a dummy field in the many-to-many model declaration in the schema.prisma file. But if we do that we actually NEED the "dummy" column to exist in the table as well. And we don't like that much. I tried adding a computed field or a simple
t*.*string('dummy', { nullable: true });
in the nexus
objectType
definition, instead of in
schema.prisma
, but it didn't work and the bug with the type generation still happened. So I can conclude that the field must be in the schema.prisma file. At least as a quick fix for that issue ----- Or I could use implicit many-to-many, instead of it being explicit. But then, we'd have to name our columns "A" and "B", and also have underscores in our table names, and we also don't like much, and we don't understand why we can't have our own names. --- But in the end we'll have to chose what we thing it's best. Having a "dummy" column, or having the columns be named "a" or "b"
💯 1