-
Notifications
You must be signed in to change notification settings - Fork 1
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
Conversation
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' }; |
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.
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
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.
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?
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.
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.
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.
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!
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.
Yea that's a good idea. I've moved this to an interface in the DatasourceWithAsyncBackend.ts file.
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.
more thinking out loud questions, exciting stuff
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' }; |
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.
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?
@@ -64,7 +64,7 @@ export function FillValueSelect<TQuery extends DataQuery & Record<string, any>>( | |||
}, | |||
}) | |||
} | |||
onBlur={() => props.onRunQuery()} | |||
onBlur={() => props?.onRunQuery?.()} |
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.
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?.(); |
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.
@iwysiu you only changed one, but all the calls should be props.onRunQuery?
😅
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.
oops, i did not realize there were multiple
src/ConnectionConfig.tsx
Outdated
// eslint-disable-next-line react-hooks/exhaustive-deps | ||
}, [currentProvider, options, onOptionsChange]); |
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.
mmh, why don't you add awsAllowedAuthProviders to the array?
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.
done!
expect(actual).toEqual(expected); | ||
}); | ||
|
||
describe('requestLooper', () => { |
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.
Here's the docs for RxJS testing https://rxjs.dev/guide/testing/marble-testing
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.
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.
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.
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.
src/AsyncDatasourceWithBackend.ts
Outdated
cancel(target: TQuery) { | ||
this.storeQuery(target, { shouldCancel: true }); | ||
} | ||
} |
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.
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'], |
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.
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.
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.
I pulled down Grafana v8.4.7 to test and I didn't see any errors.
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.
Okay good, thanks for testing!
0a916bb
to
8772b7f
Compare
36f0917
to
44ed604
Compare
44ed604
to
5aba4d9
Compare
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.
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'], |
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.
Okay good, thanks for testing!
🚀 |
Revert "Merge pull request #21 from grafana/long-running-queries"
No description provided.