Skip to content
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

Support Task-based Queries #85

Closed
6 tasks done
winsmith opened this issue Feb 8, 2022 · 0 comments
Closed
6 tasks done

Support Task-based Queries #85

winsmith opened this issue Feb 8, 2022 · 0 comments
Assignees

Comments

@winsmith
Copy link
Contributor

winsmith commented Feb 8, 2022

Task based queries have arrived on the server, now we have to support them in the client apps.

Architecture-wise, it is smart to separate get the query for an insight from calculate the result for a query. This is why we should create two views/components: The Insight view and the Query view.

Insight View

The insight view gets an insight ID as a parameter and has access to the API service. The insight view's job is to

  • retrieve the insight from the API with GET /v2/insights/${insightID}/
  • generate a query from the insight via the API with GET /v3/insights/${insightID}/query/${startDate}/${endDate}/${testMode}/
  • pass the generated query and it's displayMode to the Query View

In the UI, the display view should be responsible for displaying the title of the insight, and be a container for the query view.

Query View

A Query View's job is to take a native query, run it on the server, and display its result in an appropriate way (see #84 for more details on displaying query results).

To do that, a Query View will retrieve a task ID for the given query, immediately check if there are old results for the given query, and update when newly calculated results for the query come in. These are the units of work a query view should do:

Retrieve a Task ID

We retrieve and store a task ID for the calculation task for this query. The relevant API endpoint currently triggers a new calculation every time we ask for a task ID, but that shouldn't matter to us. It might switch to just returning the last task ID in the future. Either way, we can use the task ID to display that the query is running, to retrieve an old existing result (if any) and later to retrieve the finished result.

  • Load a task ID with POSTing the query to /v3/query/calculate-async/.

This will return a dictionary of [String: String] with one key: ["queryTaskID": queryTaskID].

Load Data

As soon as we have a task ID, we can already try and display data. The task ID might have (outdated but still valuable) query result data attached to it that we can retrieve and display while the newer query is still running.

  • Load the task ID's last successful value with GET /v3/task/${taskID}/lastSuccessfulValue/ (this will return a QueryResultWrapper)

At the same time, we want to periodically check the running task's status. It might be finished after a few milliseconds, it might run a minute or two. We'll have to periodically query it

  • Update the task status periodically with GET /v3/task/${taskID}/status/

The task status should be updated periodically:

  • Every 0.5 seconds when the last time it was queried the status was "running"
  • Every 10 seconds when the last time it was queried the status was "successful"
  • Never when the last time it was queried the status was "error'

Also, if the task status is successful, we should immediately load the last successful value again.

Reference Implementation

The JavaScript Implementation of this loading feature might give some more orientation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants