prisma
Studio runs table query twice after data modification
Bug description
Prisma Studio seems to be running a query that refreshes data after modification twice. At least this is what the browser's console is printing. It's not happening when data is just refreshed using the Refresh button. The second query run is exactly the same as the first one.
How to reproduce
- Modify/Delete a row using Prisma Studio
- Take a look at the browser's console log
- The same Running Query will be shown twice
Expected behavior
Prisma Studio should not run a table query twice when data is changed
Prisma information
--
Environment & setup
- OS: MacOs
- Browser: Chrome
- Database: MySQL
Screenshot of page where the problem happened (if applicable)
Prisma logs
No response
1. Increasing users' usage of database reads (that in most cases translates directly to increased costs)
Here I can see this may, or may not, be (that big of an) issue.
If someone uses Studio heavily (like I do, eg. to test things during development when UI is not fully functional yet) and don't use tools like Postman to edit data, this may get worst.
For example, I currently work with a table that has over 10 relations. For each row in my table (and Studio fetches a hundred rows per page) it does also read all the related data in order to display the relations. So it's over 10 actual database reads for one row in my table. This translates to 1000 database reads to only display one page.
With doubled fetching, it's 2000 for any change that I perform. If I change one row's field from 'foo' to null this is 2000 reads. For some people, this may be better, and for some worse, really depending on a number of relations.
On one hand, this counts mostly for developers on some free tiers for which such doubling of reads in important and they actually use the Studio a lot. But on the other also big players might be affected because of the larger amount of data in DB / developers using Studio / higher tables complexity, that they have. So this may impact all sorts of users.
Even if this does not doubles Prisma User's DB usage, this may probably be 3-5-10-20% increase in DB reads depending on a User. This directly translates to higher costs of operating DB, which are usually based on the amount of reads.
2. However, this may also be a Studio's performance issue.
What I mean is that for me the Studio view is only updated after the second fetch (yes, there are two fetches in the Network tab happening). So it seems like the first fetch's data is lost or something weird is happening. Updating data with Studio was always a little clunky and maybe that's the actual issue.
The second fetch just doubles dev's waiting time. Blue line and below is the second fetch:
Because data is only updated after the second fetch, and not after the first one. And this causes double the waiting time after each data modification.
Ok, so answer is "not really" but obviously it has performance implications (database usage, Studio UI performance).