Exploration Inconsistency when Corresponding Table is Deleted

[Aritra8438]

Description

When we create an exploration, we need to choose a From table. If that table is deleted, the exploration based on that is not deleted automatically (in frontend) resulting in inconsistency (let's say them dangling explorations). if we then open the exploration, there shows an error Invalid pk "193" - object does not exist.

Adding a video file to better understand the situation (error view in 30th second):

mathesarr.mp4

Expected behavior

There are some observations:

• Even after the table is deleted, we can edit the dangling exploration and assign it to a new table. But we can't save it after the reassignment (throws error Not Found)
• There needs to be at least one existing table for that, otherwise we need to delete the exploration.
• Once reloaded, all the dangling explorations are removed from the explorations tab (that means, they were already deleted from the database).

Based on those, we may have two solutions,

1. Delete all those dangling explorations from the explorations tab once the corresponding tables are deleted.
2. Allow assigning dangling explorations to another table and successfully save them.

In both cases, the minimum we need is not to show an error Invalid pk "193" - object does not exist. that might not be interpreted by a user but rather to show them the root cause and alternative solutions.

To Reproduce

• create a table, say table_1
• create an exploration from table_1, say exploration_1
• delete table_1
• now open exploration_1, it will show an error.
• reload the page, those dangling explorations won't show up again.

Environment

• OS: Ubuntu 22.04.1 LTS
• Browser: Google Chrome
• Browser Version: 111.0.5563.111 (Official Build) (64-bit)

[Aritra8438]

I want to work on this issue as well (if labels are appropriate). Also, please suggest a solution that you think will be better.
The backend deletes the explorations once the corresponding table is deleted, but keeping those dangling explorations and allowing reassignment would lessen the user modification needed.

[rajatvijay]

@Aritra8438 I prefer the first option.

Delete all those dangling explorations from the explorations tab once the corresponding tables are deleted.

But note this only requires to re-fetch the queries for the schema once a table is deleted.

In both cases, the minimum we need is not to show an error Invalid pk "193" - object does not exist. that might not be interpreted by a user but rather to show them the root cause and alternative solutions.

I don't think we need to show any error if we re-fetch the queries.

In addition to this, I also suggest showing some kind of warning to the user inside the delete table confirmation modal by saying something like:

Deleting this table will also delete all of the explorations built on top of it. Are you sure you want to proceed?

cc: @pavish adding this to v0.1.3 since this seems important from the perspective of UX.