-
Notifications
You must be signed in to change notification settings - Fork 207
Add query history items at query start time #246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add query history items at query start time #246
Conversation
Add query history items right when the user initiates a query, rather than waiting until query compilation/execution has finished. This leads to a more predictable ordering of query history items.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern with this PR relates to the synchronisation of the selected item in the query history view with the query results view. In other words, I think the query results view should always show the results for the selected query history item.
This is already to some extent an existing issue, since queries with errors can be selected. However adding query history items for in-progress queries makes this a worse experience since:
- There is no visual indication that a query history item is in-progress, so it's not obvious that the results view is showing the results of a different query history item.
- The in-progress history item is automatically selected as soon as the query starts running, so it's far more likely the history view and results view will be out of sync.
Proposal:
- When a query run is started, an in-progress query history item is added to the query history list but is not automatically selected.
- When a query run finishes, if it is the most recent query run in the query history list, the corresponding query history item is selected, and the results view is updated with the results of that query.
- It is not possible to select in-progress or errored query history items.
- The results view is always synced with the selected query history item.
- The results view always shows a
CompletedQuery
, i.e. a query with results.
|
||
get didRunSuccessfully(): boolean { | ||
return this.result.resultType === messages.QueryResultType.SUCCESS; | ||
get hadErrors(): boolean { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest renaming to didFinishWithErrors
or similar to be reinforce that this query could still be running.
archiveFilesystemProvider.activate(ctx); | ||
|
||
async function showResultsForCompletedQuery(query: CompletedQuery, forceReveal: WebviewReveal): Promise<void> { | ||
async function showResultsForCompletedQuery(query: RunningOrCompletedQuery, forceReveal: WebviewReveal): Promise<void> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename this to reflect that the query may not be completed, or reintroduce the CompletedQuery
type as a refinement of RunningOrCompletedQuery
The statement
I think it might be simpler if the results view actually presents some visual that conveys 'this query terminated with an error' (maybe even showing a useful error message) or a spinner animation or something to indicate that the query is still running, if it is? Selecting the item for the just-started query (before it has finished) makes sense to me, if the results view changes from 'still running spinner' to the actual results when the query finishes. |
For the use case of progressively refining a QL query, I think continuing to show the previous results until the new results are available (instead of displaying a spinner in the results view as soon as the new query run is started) would be valuable. |
Closing for now, need to rethink approach. |
Add query history items right when the user initiates a query, rather
than waiting until query compilation/execution has finished. This
leads to a more predictable ordering of query history items.
This doesn't affect user-facing behavior other than timing.
Fixes https://github.com/github/codeql-coreql-team/issues/277