Hmm, I have a question, is there any way to have a...
# orm-help
c
Hmm, I have a question, is there any way to have a sort of generic "Bridge Table" in a Prisma schema? Like. e.g., "Taggable" which would have fields: id, tag_id, taggable_id, taggable_type (which would be an enum of the possible tables linked to). This pattern can be done easily enough in SQL (with where clause for select, and a field inserted in creates/updates) and is pattern that was (possibly is, haven't done it in a while) in the ActiveRecord component of Rails. If a domain has lots of many-on-many relations it can help keep down a proliferation of bridge tables. I'm concerned the "@ relation" directive makes this not possible.
c
hmm, that’s a good question. i imagine it might be difficult to maintain referential integrity to know which table each fk refers to. i suppose you could have an open-ended list of Strings as in the first example here: https://www.prisma.io/docs/concepts/components/prisma-schema/data-model#lists
and then perhaps you could write a manual migration that adds a trigger on update to each taggable entity: https://www.sqlservertutorial.net/sql-server-triggers/sql-server-create-trigger/
generally, we’ll create all of our manual sql-level schema changes separate from the manual ones by putting them in different migration subfolders/files
but, technically, you could also modify the automatically-generated migration that adds the tag fields and tables and just put your triggers at the end of that file
c
Keeping track of which table the FK references is not hard, you use a field to mark it. In AR practice the field would be called e.g.,
taggable_type
. I have the following code:
Copy code
model TagsOnPanels {
  id  Int  @id
  tagId Int
  tag  Tag  @relation(fields: [tagId], references: [id])
  panelId Int
  panel Panel @relation(fields: [panelId], references: [id])
}
With what could I replace the line starting
panel Panel
with?
Hunh, Slack won't allow the backtick on multiple lines.
Do I need to just have an
Int
field in the model for the FK, handle all the relations by hand with SQL? How would that affect the Prisma calls?
c
that’s a good question and i don’t know if i have a reliable answer unfortunately. in my experience, it’s likely that your queries would then need to be two-phase bc you couldn’t directional select the related tags in a single prisma-native query
however, if you use something like a DataLoader, you could likely reduce the number of lookups you’d need to do for related tags within the same HTTP request: https://github.com/graphql/dataloader
we integrate DataLoaders pretty frequently when we need to federate data from prisma/pg and other data systems like Contentful, Elasticsearch, etc
if you’re doing Apollo GraphQL, we also often wrap our DataLoaders in an Apollo DataSource so that the abstraction is cleaner in our resolvers: https://www.apollographql.com/docs/apollo-server/data/data-sources/
t
this is similar to my feature request https://github.com/prisma/prisma/issues/8848
also, @Craig A. Cook, multi-line code uses three backticks "```"
actually re-reviewing your question makes it sound like you want Polymorphic relations https://github.com/prisma/prisma/issues/1644 https://github.com/prisma/prisma/issues/2505
c
I think that's what they were called in Rails. If one has a very inter-connected domain with m models all of which are many-to-many with every other model, having to do the bridge table for each results in if I did this right, sum(m .. 1)-1, rather than m+1 tables (and relationship code).