[Build] unused dependency opensearch-datemath
#6311
Assignees
Labels
Comments
kavilla
changed the title
opensearch-datemath
|
Doing this while doing my project work. |
7 tasks
7 tasks
kavilla
added a commit
that referenced
this issue
May 9, 2024
Enable with `data.enhancements.enabled: true` Allows for enhancing the data plugin UI service and search service. #### Remaining work * Address issue with time range being invalid if previous state successfully queried and set it with a time range format that is invalid for the new query language * For example, DQL with quick time range (4 weeks to now), get results. Switch to PPL, even though PPL has a default time range enhancement. The props date range saved in the app state takes priority and sets the time range to quick range causing an error. I can still modify the time range and get a successful query but it will first fail until the user updates it to a non quick time range. * Add tests * Disable for plugins that do not support the functionality * By default index patterns are created with a unique ID. However, it can be enabled to create an index pattern with a custom ID that matches the name of the index pattern (which in turn maps to indices). * For seamless integration, the temp data frame would need to check if the index pattern that maps to the data frame name. And get it's id. * This means that dashboards with visualizations that were created with an index pattern unique ID still require the existing index pattern to exist in memory. ### Issues Resolved closes #6639 closes #6311 partially resolves: #5504 * add error data frame Signed-off-by: Paul Sebastian <paulstn@amazon.com> move language to left, some styling and disable per app name Signed-off-by: Kawika Avilla <kavilla414@gmail.com> --------- Signed-off-by: Kawika Avilla <kavilla414@gmail.com> Signed-off-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com>
abbyhu2000
pushed a commit
to abbyhu2000/OpenSearch-Dashboards
that referenced
this issue
May 9, 2024
Enable with `data.enhancements.enabled: true` Allows for enhancing the data plugin UI service and search service. * Address issue with time range being invalid if previous state successfully queried and set it with a time range format that is invalid for the new query language * For example, DQL with quick time range (4 weeks to now), get results. Switch to PPL, even though PPL has a default time range enhancement. The props date range saved in the app state takes priority and sets the time range to quick range causing an error. I can still modify the time range and get a successful query but it will first fail until the user updates it to a non quick time range. * Add tests * Disable for plugins that do not support the functionality * By default index patterns are created with a unique ID. However, it can be enabled to create an index pattern with a custom ID that matches the name of the index pattern (which in turn maps to indices). * For seamless integration, the temp data frame would need to check if the index pattern that maps to the data frame name. And get it's id. * This means that dashboards with visualizations that were created with an index pattern unique ID still require the existing index pattern to exist in memory. closes opensearch-project#6639 closes opensearch-project#6311 partially resolves: opensearch-project#5504 * add error data frame Signed-off-by: Paul Sebastian <paulstn@amazon.com> move language to left, some styling and disable per app name Signed-off-by: Kawika Avilla <kavilla414@gmail.com> --------- Signed-off-by: Kawika Avilla <kavilla414@gmail.com> Signed-off-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com>
ashwin-pc
pushed a commit
that referenced
this issue
May 10, 2024
Enable with `data.enhancements.enabled: true` Allows for enhancing the data plugin UI service and search service. * Address issue with time range being invalid if previous state successfully queried and set it with a time range format that is invalid for the new query language * For example, DQL with quick time range (4 weeks to now), get results. Switch to PPL, even though PPL has a default time range enhancement. The props date range saved in the app state takes priority and sets the time range to quick range causing an error. I can still modify the time range and get a successful query but it will first fail until the user updates it to a non quick time range. * Add tests * Disable for plugins that do not support the functionality * By default index patterns are created with a unique ID. However, it can be enabled to create an index pattern with a custom ID that matches the name of the index pattern (which in turn maps to indices). * For seamless integration, the temp data frame would need to check if the index pattern that maps to the data frame name. And get it's id. * This means that dashboards with visualizations that were created with an index pattern unique ID still require the existing index pattern to exist in memory. closes #6639 closes #6311 partially resolves: #5504 * add error data frame move language to left, some styling and disable per app name --------- Signed-off-by: Kawika Avilla <kavilla414@gmail.com> Signed-off-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: Kawika Avilla <kavilla414@gmail.com> Co-authored-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com>
abbyhu2000
added a commit
to abbyhu2000/OpenSearch-Dashboards
that referenced
this issue
May 10, 2024
…pensearch-project#6760) Enable with `data.enhancements.enabled: true` Allows for enhancing the data plugin UI service and search service. * Address issue with time range being invalid if previous state successfully queried and set it with a time range format that is invalid for the new query language * For example, DQL with quick time range (4 weeks to now), get results. Switch to PPL, even though PPL has a default time range enhancement. The props date range saved in the app state takes priority and sets the time range to quick range causing an error. I can still modify the time range and get a successful query but it will first fail until the user updates it to a non quick time range. * Add tests * Disable for plugins that do not support the functionality * By default index patterns are created with a unique ID. However, it can be enabled to create an index pattern with a custom ID that matches the name of the index pattern (which in turn maps to indices). * For seamless integration, the temp data frame would need to check if the index pattern that maps to the data frame name. And get it's id. * This means that dashboards with visualizations that were created with an index pattern unique ID still require the existing index pattern to exist in memory. closes opensearch-project#6639 closes opensearch-project#6311 partially resolves: opensearch-project#5504 * add error data frame move language to left, some styling and disable per app name --------- Signed-off-by: Kawika Avilla <kavilla414@gmail.com> Signed-off-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: Kawika Avilla <kavilla414@gmail.com> Co-authored-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com>
yujin-emma
pushed a commit
to yujin-emma/OpenSearch-Dashboards
that referenced
this issue
May 10, 2024
Enable with `data.enhancements.enabled: true` Allows for enhancing the data plugin UI service and search service. #### Remaining work * Address issue with time range being invalid if previous state successfully queried and set it with a time range format that is invalid for the new query language * For example, DQL with quick time range (4 weeks to now), get results. Switch to PPL, even though PPL has a default time range enhancement. The props date range saved in the app state takes priority and sets the time range to quick range causing an error. I can still modify the time range and get a successful query but it will first fail until the user updates it to a non quick time range. * Add tests * Disable for plugins that do not support the functionality * By default index patterns are created with a unique ID. However, it can be enabled to create an index pattern with a custom ID that matches the name of the index pattern (which in turn maps to indices). * For seamless integration, the temp data frame would need to check if the index pattern that maps to the data frame name. And get it's id. * This means that dashboards with visualizations that were created with an index pattern unique ID still require the existing index pattern to exist in memory. ### Issues Resolved closes opensearch-project#6639 closes opensearch-project#6311 partially resolves: opensearch-project#5504 * add error data frame Signed-off-by: Paul Sebastian <paulstn@amazon.com> move language to left, some styling and disable per app name Signed-off-by: Kawika Avilla <kavilla414@gmail.com> --------- Signed-off-by: Kawika Avilla <kavilla414@gmail.com> Signed-off-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: Paul Sebastian <paulstn@amazon.com> Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com> Signed-off-by: yujin-emma <yujin.emma.work@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
We have within our repo:
https://github.com/opensearch-project/OpenSearch-Dashboards/tree/main/packages/opensearch-datemath
But it is not used within our repo. We install the legacy package and use that:
https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/package.json#L138
That means we unused code in our repo that we build every time.
Describe the solution you'd like
To avoid breaking issues:
"@elastic/datemath": "link:packages/opensearch-datemath",Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: