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

Long Running Queries #21

Merged
merged 16 commits into from
Nov 3, 2022
Merged

Long Running Queries #21

merged 16 commits into from
Nov 3, 2022

Conversation

kevinwcyu
Copy link
Contributor

No description provided.

@CLAassistant
Copy link

CLAassistant commented Aug 30, 2022

CLA assistant check
All committers have signed the CLA.

@kevinwcyu kevinwcyu requested a review from sunker August 30, 2022 19:45
src/sql/types.ts Outdated
@@ -7,4 +7,5 @@ export interface SQLQuery extends DataQuery {
rawSQL: string;
format?: number;
fillMode?: { mode: FillValueOptions; value?: number };
meta?: { queryFlow?: 'async' | 'sync' };
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The frontend sends this to the backend to determine whether to use the sync (existing) query flow or the async query flow. The frontend sets this field based on a feature toggle. This is sent from the frontend because external plugins cannot access Grafana backend feature toggles

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it odd that this would be saved in the query? How would we update old queries? if we have to revert after releasing would that be ok if queries are saved with this field?

I wonder if we could somehow right our frontend code to make the query not knowing if it is sync or async and then make different choices based on the response from the backend instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be saved in the query. The frontend adds this to the query right before it is executed. So old queries wouldn't need to know about this field. If I'm not mistaken, this only gets saved in the query if it's called with onChange, which isn't called between the time this field is added and when we execute the query. Here's where it's added in the redshift datasource https://github.com/grafana/redshift-datasource/pull/177/files#diff-804a5756e358074cb0ba27b1932cca77d39b90694fc1d4d122f46348c8653259R113.

The backend would need to decide when to run a query sync or async. Right now, we decide that based on a feature toggle. But since external plugins don't have access to the Grafana backend feature toggles, we're reading it from the frontend and making the decision there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah interesting. I wonder if it would somehow make sense to move this out of the query object then? Like it's own separate state concept? Open to whatever you think is best though!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea that's a good idea. I've moved this to an interface in the DatasourceWithAsyncBackend.ts file.

@kevinwcyu kevinwcyu requested review from a team and fridgepoet and removed request for a team August 31, 2022 12:51
Copy link
Member

@sarahzinger sarahzinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more thinking out loud questions, exciting stuff

src/sql/QueryEditor/FillValueSelect.tsx Show resolved Hide resolved
src/sql/types.ts Outdated
@@ -7,4 +7,5 @@ export interface SQLQuery extends DataQuery {
rawSQL: string;
format?: number;
fillMode?: { mode: FillValueOptions; value?: number };
meta?: { queryFlow?: 'async' | 'sync' };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it odd that this would be saved in the query? How would we update old queries? if we have to revert after releasing would that be ok if queries are saved with this field?

I wonder if we could somehow right our frontend code to make the query not knowing if it is sync or async and then make different choices based on the response from the backend instead?

@iwysiu iwysiu marked this pull request as ready for review September 23, 2022 19:30
@@ -64,7 +64,7 @@ export function FillValueSelect<TQuery extends DataQuery & Record<string, any>>(
},
})
}
onBlur={() => props.onRunQuery()}
onBlur={() => props?.onRunQuery?.()}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit but props should be defined (at least according to the function signature), so all the calls should be props.onRunQuery?

@@ -43,7 +43,7 @@ export function FillValueSelect<TQuery extends DataQuery & Record<string, any>>(
// Keep the fillMode.value in case FillValueOptions.Value mode is selected back
fillMode: { ...props.query.fillMode, mode: value },
});
props.onRunQuery();
props?.onRunQuery?.();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iwysiu you only changed one, but all the calls should be props.onRunQuery? 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, i did not realize there were multiple

Comment on lines 57 to 58
// eslint-disable-next-line react-hooks/exhaustive-deps
}, [currentProvider, options, onOptionsChange]);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mmh, why don't you add awsAllowedAuthProviders to the array?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

expect(actual).toEqual(expected);
});

describe('requestLooper', () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's the docs for RxJS testing https://rxjs.dev/guide/testing/marble-testing

Copy link
Member

@sarahzinger sarahzinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't do any manual testing here, but let me know if you'd like me to!

I think this looks cool from a code perspective to me :) Small suggestion to add a PR description so that if we're ever looking through the git history we can get some more context.

src/sql/QueryEditor/FillValueSelect.tsx Show resolved Hide resolved
Copy link
Contributor

@sunker sunker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for moving the async data stuff to this package. It makes it much easier to understand how this feature will be used as a service. Just one concern in the comments.

cancel(target: TQuery) {
this.storeQuery(target, { shouldCancel: true });
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this file should be called DataSourceWithAsyncBackend instead? Thoughts?

@@ -26,7 +26,7 @@ const buildCjsPackage = ({ env }) => {
},
},
],
external: ['react', '@grafana/data', '@grafana/ui', 'lodash'],
external: ['react', '@grafana/data', '@grafana/ui', '@grafana/runtime', 'lodash', 'rxjs'],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason this grafana/aws-sdk did not use grafana/runtime previously was because before Grafana 9.0, grafana/ui depended on grafana/aws-sdk. This created an implicit dependency between grafana/ui and grafana/runtime and that is really bad.

This dependency was removed in 9.0, so this should be totally fine for any user running that version or newer versions of Grafana. However, I believe AMG are still running 8.4.x, so I think the long running queries feature must be compatible with that version. Just to make sure I'm correct on this, can you try and build all repos involded in the long running queries feature together with Grafana 8.4.x? If this doesn't work, we may have to break out the AsyncDataSourceWithBackend.ts (that's the only file who needs the runtime, no?) into a new "AsyncDataSourceBackend" repo/npm package. That wouldn't be so bad anyway because the long term intent is that this feature is made available for wider use beyond just AWS plugins.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pulled down Grafana v8.4.7 to test and I didn't see any errors.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay good, thanks for testing!

@kevinwcyu kevinwcyu force-pushed the long-running-queries branch 3 times, most recently from 0a916bb to 8772b7f Compare October 12, 2022 21:55
@kevinwcyu kevinwcyu force-pushed the long-running-queries branch 4 times, most recently from 36f0917 to 44ed604 Compare October 12, 2022 22:05
package.json Outdated Show resolved Hide resolved
.drone.yml Outdated Show resolved Hide resolved
@kevinwcyu kevinwcyu mentioned this pull request Oct 28, 2022
@kevinwcyu kevinwcyu requested a review from sunker November 1, 2022 13:56
Copy link
Contributor

@sunker sunker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work!

@@ -26,7 +26,7 @@ const buildCjsPackage = ({ env }) => {
},
},
],
external: ['react', '@grafana/data', '@grafana/ui', 'lodash'],
external: ['react', '@grafana/data', '@grafana/ui', '@grafana/runtime', 'lodash', 'rxjs'],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay good, thanks for testing!

@kevinwcyu kevinwcyu merged commit ce0695d into main Nov 3, 2022
@kevinwcyu kevinwcyu deleted the long-running-queries branch November 3, 2022 14:53
@andresmgot
Copy link
Collaborator

🚀

kevinwcyu added a commit that referenced this pull request Nov 3, 2022
This reverts commit ce0695d, reversing
changes made to b67da1e.
kevinwcyu added a commit that referenced this pull request Nov 4, 2022
Revert "Merge pull request #21 from grafana/long-running-queries"
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

Successfully merging this pull request may close these issues.

None yet

6 participants