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

[Discover]chore: disable sorting on columns header for PPL and SQL #9263

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Maosaic
Copy link
Contributor

@Maosaic Maosaic commented Jan 23, 2025

Description

Disable sorting on columns header for PPL and SQL,

Issues Resolved

Currently sorting on Discover table columns header does not support PPL and SQL, disable it until we build sorting support for PPL and SQL.

Screenshot

Screen.Recording.2025-01-22.at.10.36.39.AM.mp4

Testing the changes

Changelog

  • chore: Disable sorting on Discover table columns header for PPL and SQL

Check List

  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
  • New functionality includes testing.
  • New functionality has been documented.
  • Update CHANGELOG.md
  • Commits are signed per the DCO using --signoff

Copy link

codecov bot commented Jan 23, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.68%. Comparing base (0be70a7) to head (9eef96e).
Report is 3 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #9263   +/-   ##
=======================================
  Coverage   61.68%   61.68%           
=======================================
  Files        3816     3816           
  Lines       91693    91695    +2     
  Branches    14516    14516           
=======================================
+ Hits        56557    56559    +2     
  Misses      31510    31510           
  Partials     3626     3626           
Flag Coverage Δ
Linux_1 29.04% <0.00%> (-0.01%) ⬇️
Linux_2 56.46% <0.00%> (ø)
Linux_3 39.09% <100.00%> (?)
Linux_4 28.97% <0.00%> (-0.01%) ⬇️
Windows_1 29.06% <0.00%> (-0.01%) ⬇️
Windows_2 56.41% <0.00%> (ø)
Windows_3 39.09% <100.00%> (+<0.01%) ⬆️
Windows_4 28.97% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ananzh ananzh added bug Something isn't working discover-next labels Jan 23, 2025
@ananzh ananzh added the v2.19.0 label Jan 23, 2025
Copy link
Contributor

@angle943 angle943 left a comment

Choose a reason for hiding this comment

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

I have tested this change manually and the functionality works as expected!

Just FYI i will update my cypress test PR that tests for language-specific display and update it to ensure that sort works as expected (so it is dependent upon your PR being merged): #9215

return {
name: column,
displayName: isShortDots ? shortenDottedString(column) : column,
isSortable: field && field.sortable ? true : false,
isSortable:
osdFieldOverrides.sortable == null ? !!field?.sortable : osdFieldOverrides.sortable,
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: is the !! necessary for !!field?.sortable? The combination of !! and ? (on top of the ternary) is hurting my brain

Copy link
Contributor

Choose a reason for hiding this comment

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

but on top of that i think nullish coalescing operator will help readability here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

!!field?.sortable is the short handed version of previous code field && field.sortable ? true : false

Copy link
Contributor

Choose a reason for hiding this comment

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

i understand that, but isn't field?.sortable sufficent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We need false if sortable is undefined

Copy link
Contributor

Choose a reason for hiding this comment

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

ah sortable is an optional field?

@@ -78,7 +78,7 @@ export const getFilterableOsdTypeNames = (): string[] =>
registeredOsdTypes.filter((type) => type.filterable).map((type) => type.name);

export const setOsdFieldOverrides = (newOverrides: { [key: string]: any } | undefined) => {
osdFieldOverrides = newOverrides ? Object.assign({}, osdFieldOverrides, newOverrides) : {};
osdFieldOverrides = newOverrides ? Object.assign({}, newOverrides) : {};
};

export const getOsdFieldOverrides = (): { [key: string]: any } => {
Copy link
Contributor

Choose a reason for hiding this comment

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

(unrelated to your PR) why is there osd_field_types.ts and old_field_type.ts in this directory?

@@ -78,7 +78,7 @@ export const getFilterableOsdTypeNames = (): string[] =>
registeredOsdTypes.filter((type) => type.filterable).map((type) => type.name);

export const setOsdFieldOverrides = (newOverrides: { [key: string]: any } | undefined) => {
osdFieldOverrides = newOverrides ? Object.assign({}, osdFieldOverrides, newOverrides) : {};
Copy link
Contributor

Choose a reason for hiding this comment

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

(clarifying comment). I'm trying to understand this change. So initially:

  • if newOverrides, then osdFieldOverrides would include both properties of osdFieldOverrides and newOverrides, else it would be empty object

With your change:

  • if newOverrides, it would just be newOverrides, else an empty object?

Yours make sense to me, but the original code doesn't make much sense. It would make more sense if on the else condition of the ternary, the osdFieldOverrides was getting applied, but the way it is written it looks like that is appearing out of nowhere

Copy link
Contributor

Choose a reason for hiding this comment

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

(but now more of a nitpick): Would it be better if we just did:

osdFieldOverrides = {...newOverrides}

?

it would cover the undefined case as well

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'm align with your suggestion, I was trying to introduce less change if possible, also want to have @kavilla align with the change here.

Copy link
Member

Choose a reason for hiding this comment

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

correct it made sense at one time for this code but this was essentially dead code.

DQLBody,
QueryEditorExtensionConfig,
SingleLineInput,
UiEnhancements,
Copy link
Contributor

Choose a reason for hiding this comment

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

(clarifying comment) did this UiEnhancements type never exist? I'm trying to find it in my IDE but can't find it :/

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 is unrelated to the code change of disabling sorting, but a ts error I found when I touching the file.

I think this was supposed to be updated in #PR7731 , and this is why I think we should not bypass ts error when building

Copy link
Member

Choose a reason for hiding this comment

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

it did but the delta of changes involved in changing it close to cut off dates made it not worth it with a lot changing. so thanks for fixing it.

@@ -83,12 +90,14 @@ export function getLegacyDisplayedColumns(
if (!Array.isArray(columns) || typeof indexPattern !== 'object' || !indexPattern.getFieldByName) {
return [];
}
// TODO: Remove overrides once we support PPL/SQL sorting
Copy link
Member

Choose a reason for hiding this comment

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

did we want to create an issue and track it on github and link a reference in here?

@@ -5,8 +5,11 @@

import { getLegacyDisplayedColumns } from './helper';
import { IndexPattern } from '../../../opensearch_dashboards_services';
import { getOsdFieldOverrides } from 'src/plugins/data/common/osd_field_types/osd_field_types';
Copy link
Member

Choose a reason for hiding this comment

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

did we want to import similiar to the actual file

import { getOsdFieldOverrides } from 'src/plugins/data/common';

Copy link
Member

@kavilla kavilla left a comment

Choose a reason for hiding this comment

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

just some nits. but lgtm.

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

Successfully merging this pull request may close these issues.

4 participants