prisma
v7: Show reverse relations
It would be extremely useful to show reverse relations for each table, such as User.posts. That is, showing a posts column when viewing the User table, which the user can click to preview/open those filtered rows in a new tab.
This has been a killer feature of Prisma Studio up until v7.
Hey 👋
Thank you! 🙏
This is doable. Presentation/cost is in question.
We don't have the extra details of PSL metadata, by design - maybe in the future, as enrichment. No virtual field name you picked to display. In most cases we don't have the semantic meaning of the relation.
Only got foreign key, schema, table, and column name to work it.
Foreign key names are unique but rarely given any attention OR completely hidden from users of ORMs when the constraint is created.
Schema + Table + Column is potentially a very long combo - table names alone are around 60 characters max.
Better UX would come with not allowing to traverse the relation if the current record has no related record on the other side. So for each record we'd need to query other tables and count, for every relation in that direction.
In big production systems, this could mean - lots of relations x lots of records on the other side to read, every time you get a page of the original table.
Hey @igalklebanov, thanks for the response!
Just for clarity on what I'm looking for here, I've attached a video for how this works in Prisma v6.19:
https://github.com/user-attachments/assets/6890ae0d-5bf9-4fac-b923-bd82a39ec17e
We don't have the extra details of PSL metadata, by design
By this, do you mean that this has changed with v7 of Prisma Studio, so that you no longer pull the necessary context to achieve this right now?
lots of relations x lots of records on the other side to read, every time you get a page of the original table
Yes I agree, and this could actually cause things to load pretty slowly in Prisma Studio for tables with a lot of relations. I'm not sure what queries are/were happening to make this happen, but figured it might make sense to just do a COUNT(*) for the relations, to show how many there are, and then only load the related data when clicking the field, as shown when clicking the Session in that video above.
Also, I'm not sure if this is relevant, but would the future changes described at https://github.com/prisma/prisma/issues/27028#issuecomment-3265334095 impact things here?
By this, do you mean that this has changed with v7 of Prisma Studio, so that you no longer pull the necessary context to achieve this right now?
Prisma ORM and Prisma Studio are 2 separate products now. New Studio is SQL-first, ORM agnostic.
We have the necessary context to achieve this, we might lack some semantic meaning of relations, that otherwise, a virtual foreign field you define in your schema file would provide.
Yes I agree, and this could actually cause things to load pretty slowly in Prisma Studio for tables with a lot of relations. I'm not sure what queries are/were happening to make this happen, but figured it might make sense to just do a COUNT(*) for the relations, to show how many there are, and then only load the related data when clicking the field, as shown when clicking the Session in that video above.
You still pay the price of fetching a lot of rows in count queries, a full table scan at worst if there's no fitting index. In PostgreSQL you also might pay for visibility checks.
Is showing exact number of related records that important? You're going to find out anyway once you traverse to the filtered view of the related table.
I believe the only thing that matters is if it has or has no related records in the referencing column.
Given that, a select exists select 1 from ... where ... is supposed to perform a lot better as it should exit early.
Also, I'm not sure if this is relevant, but would the future changes described at https://github.com/prisma/prisma/issues/27028#issuecomment-3265334095 impact things here?
Irrelevant. New Studio is ORM agnostic.
Is showing exact number of related records that important? You're going to find out anyway once you traverse to the filtered view of the related table.
Yes it has been quite helpful in my usage -- as an example, I'll load a table with many rows, looking for all records with a certain amount of reverse related entities for a given column. Like say all rows are expected to have 3 related entities, but some only have 2, I can quickly identify those specific records from that info.
Yes it has been quite helpful in my usage -- as an example, I'll load a table with many rows, looking for all records with a certain amount of reverse related entities for a given column. Like say all rows are expected to have 3 related entities, but some only have 2, I can quickly identify those specific records from that info.
Shouldn't a filter by count(referencing_column) op value be more helpful?
e.g. count(referencing_column) < 3.
Tbh that was just an example, there are a lot of other instances I've had where knowing the exact number of related entities for each row is really helpful to understanding the content/integrity of the data. Probably every day I use it honestly.
Definitely understand why you'd be wary of adding that given the performance implications, but it is super helpful, so would be awesome if we could find a way to make it work 🙇
Please add this back—this is literally why we use prisma studio :/
Please give the issue a 👍 if you can @CaptainCrouton89 -- it signals the need for each feature
I see any comments are being hidden as spam :(
I agree with @michaelhays.
Personally for all my projects this is a huge regression from V6. Using Studio to look up nested relations now is inefficient and writing raw SQL is probably faster. It almost defeats the purpose of having a UI for managing a db in the first place.
Use case example: User with email [email protected] asks to know what documents they have relating to "Project 1" project in DB.
Prisma V6.
- Filter users by email
- Click on related Projects model
- Click on specific Project ("Project 1") in list (same screen)
- Click on Documents relation to view documents.
Prisma V7.
- Filter users by email (also in V6)
- Copy userId
- Scroll through table list to find Projects table and open it.
- Filter by userId and paste the copied userId from step 2 and find project ("Project 1").
- Copy projectId
- Go to Documents table
- Filter by projectId to view the documents.
It is longer but most importantly very tedious to copy paste relations.
Just sharing my opinion as I may have been in the intended user base as a long-time Prisma user:
New Studio is SQL-first, ORM agnostic.
I don't claim to know nor understand the reasons that pushed the team to go to this direction, but in my opinion, this is going to lose a lot of ORM users coming from v6.
What made Studio essential to my toolbelt was the fact that it was tightly coupled to my schema, understood it, and gave a UX to easily travel through my data.
I don't want a new db viewer to show my raw data, I already have pgadmin, dbeaver or dbvisualize that do that with way more feature than the new studio will probably ever have.
So, yeah. Not sure to understand the direction.
