-
Notifications
You must be signed in to change notification settings - Fork 923
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 an unified storage class for data plugin #7701
Add an unified storage class for data plugin #7701
Conversation
❌ Empty Changelog SectionThe Changelog section in your PR description is empty. Please add a valid changelog entry or entries. If you did add a changelog entry, check to make sure that it was not accidentally included inside the comment block in the Changelog section. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7701 +/- ##
==========================================
- Coverage 63.82% 63.81% -0.02%
==========================================
Files 3651 3653 +2
Lines 80951 80995 +44
Branches 12885 12892 +7
==========================================
+ Hits 51666 51683 +17
- Misses 26122 26144 +22
- Partials 3163 3168 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
} | ||
|
||
type IStorageEngine = typeof window.localStorage; | ||
export class DataStorage { |
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 do like this structure. it makes it easier to not use opensearchDashboards.
and just pass the key
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. Thank you and some nice clean ups.
Just comments but nothing blocking. If potentially can add some tests where possible.
src/plugins/data/public/ui/query_string_input/no_data_popover.tsx
Outdated
Show resolved
Hide resolved
@@ -381,13 +381,13 @@ export default class QueryStringInputUI extends Component<Props, State> { | |||
'field' in suggestion && | |||
suggestion.field.subType && | |||
suggestion.field.subType.nested && | |||
!this.services.storage.get('opensearchDashboards.DQLNestedQuerySyntaxInfoOptOut') |
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 is really nice! thank you
getHistoryKeys() { | ||
return this.storage | ||
.keys() | ||
.filter((key: string) => key.indexOf('query_') === 0) |
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.
could you explain the decision to go with query_
it makes sense to me but do we have to make it more specific to avoid potential collisions? did we look into the decision of the name of the key ssense
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 not sure about the meaning of "ssense" , but i think "_query" makes sense for saving recent query here? They full key is opensearch_dashboards.query_1723753938175
, the numbers followed are the timetamp, i think it will avoid collisions?
import { BehaviorSubject } from 'rxjs'; | ||
import { Query, TimeRange } from '../..'; | ||
|
||
// Todo: Implement a more advanced QueryHistory class when needed for recent query history |
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.
seems pretty advanced hah nice. and only has functionality for recents. or do you mean configurable
} | ||
|
||
setUserQueryLanguageBlocklist(languages: string[]) { | ||
this.storage.set( | ||
'opensearchDashboards.userQueryLanguageBlocklist', | ||
'userQueryLanguageBlocklist', | ||
languages.map((language) => language.toLowerCase()) | ||
); | ||
return true; | ||
} | ||
|
||
getUserQueryLanguage() { |
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.
to be honest i think we can start cleaning this up and centralizing the language stuff with the language manager. what do you think? or is this useful here still?
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 i plan to include these language related storage stuff in the language manager, and get rid of the settings class.
} | ||
|
||
setUserQueryLanguage(language: string) { | ||
if (language !== this.getUserQueryLanguage()) { | ||
this.search.df.clear(); | ||
} | ||
this.storage.set('opensearchDashboards.userQueryLanguage', language); |
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.
same for the rest
@@ -379,7 +379,7 @@ export default function QueryBarTopRow(props: QueryBarTopRowProps) { | |||
|
|||
function onLuceneSyntaxWarningOptOut(toast: Toast) { | |||
if (!storage) return; | |||
storage.set('opensearchDashboards.luceneSyntaxWarningOptOut', true); | |||
storage.set('luceneSyntaxWarningOptOut', 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.
nothing blocking this PR, but should we consider making apart of the language manager a generic function that will be invoked when the language is switched. developers can register a language with a function like onLanguageOptIn and onLanguageOptOut and we will call for that to do as they please. Like potentially updating a UI metric saved object.
return () => subscription.unsubscribe(); | ||
} | ||
|
||
addQueryToHistory(dataSet: string, query: Query, dateRange?: TimeRange) { |
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.
do you think we could use the SimpleDataSet object so that when I refactor to match the desired state it will be easier to catch.
Or do you see any issue with using the dataset object here.
Here is diagram:
assets/127f96cd-2e40-4f80-8e48-94bf7da84b6d">
SimpleDataSet todaywill have this information that will be important for requery.
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.
Sure modified this prop to be simple data set.
dataSet, | ||
time: timestamp, | ||
query, | ||
dateRange, |
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 is the current saved query saved object.
I think we should follow the same format and property names as the saved query.
you have query, but i would rename dataRange to timeFilter and i would include filters as well.
time could probaby could be submitted_at
should we consider workspaces @ashwin-pc ?
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.
so inside the onQueryBarSubmit
function, we only get time range as props. But time filter includes both time range and refresh interval. So do you think we need to include refresh interval and the filters here?
public onQueryBarSubmit = (queryAndDateRange: { dateRange?: TimeRange; query?: Query }) => {
@@ -371,6 +373,14 @@ class SearchBarUI extends Component<SearchBarProps, State> { | |||
} | |||
} | |||
); | |||
const dataSet = this.dataSetService.getDataSet(); |
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 think no other plugin utilizes datasets besides Discover. However, should we consider this while designing this recent query and history. Specifically the app where the query was sent. so that if the current app path is not the same app path then we do not display the query. in case one app supports different languages but another doesn't
c9a7eda
to
179c199
Compare
Signed-off-by: abbyhu2000 <[email protected]>
Signed-off-by: abbyhu2000 <[email protected]>
Signed-off-by: abbyhu2000 <[email protected]>
Signed-off-by: abbyhu2000 <[email protected]>
Signed-off-by: abbyhu2000 <[email protected]>
Signed-off-by: abbyhu2000 <[email protected]>
Signed-off-by: abbyhu2000 <[email protected]>
0955e9f
to
36ed793
Compare
* add an unified storage class Signed-off-by: abbyhu2000 <[email protected]> --------- Signed-off-by: abbyhu2000 <[email protected]> (cherry picked from commit 9a84202) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* add an unified storage class Signed-off-by: abbyhu2000 <[email protected]> --------- Signed-off-by: abbyhu2000 <[email protected]>
* add an unified storage class --------- (cherry picked from commit 9a84202) Signed-off-by: abbyhu2000 <[email protected]> Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Description
Screenshot
Testing the changes
Changelog
Check List
yarn test:jest
yarn test:jest_integration