explorerhq / sql-explorer

SQL reporting that Just Works. Fast, simple, and confusion-free. Write and share queries in a delightful SQL editor, with AI assistance.

Home Page:https://www.sqlexplorer.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Indicating whether the query still runs after changes in the DB

eeriksp opened this issue · comments

Problem statement

One issue that keeps happening for me quite often is that the saved queries no longer run after new migrations have been made and the table structure has changed.

It is time-consuming to go over each query manually to check if it still works after a database change has occurred.

Proposed solution

I propose to add a boolean field compiles to the Query model which would indicate if the query returns an error or not. This filed would be overridden every time the query is run. In the list view of the queries that could be displayed as a green/red circle, just like boolean values are displayed in Django admin.

There could also be a management command (maybe call it test_sql_queries) which would run all queries and thus update their compiles fields. ./manage.py test_sql_queries could be run after running migrations to identify the broken queries.

Since SQL explorer also permits queries that modify data, there needs to be another boolean flag which allows the query to be excluded from the set of queries ./manage.py test_sql_queries runs to prevent any unwanted data modifications.

How does that idea sound?
I could prepare a pull request if that seems to be a reasonable solution.

I'm having a think through this one.

First thing that strikes me though is what that field would get called. A query isn't compiled, it's ran or executed. So I'd be tempted to call the field something like can_run to show that the query can be ran.

I'm not sure about a 2nd field though. I think excluding queries and concern for queries modifying data would be better mitigated against using management command arguments. Maybe there could be an "exclude" argument that would exclude specified queries, and a "connection" argument that meant you could ensure the queries are ran on a connection with read-only access (docs)

Yes, your suggestions make sense.
I start to work on the PR.

Addressed in #562

Thanks so much!