fix(table-chart): time shift is not working

[justinpark]

SUMMARY

In situations where a floating number is even and the decimal number is large, there is an issue with JSONbig parse converting it to BigNumber instead of a number. This leads to a problem in the process of checking isMetric, as it recognizes that the data contains items that are not of type number, resulting in incorrect output of the time shift values.

The code addresses this issue by converting the parse section to a number.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:

After:

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[korbit-ai]

I've completed my review and didn't find any issues.

Files scanned

​

File Path	Reviewed
superset-frontend/packages/superset-ui-core/src/connection/callApi/parseResponse.ts	✅

Explore our documentation to understand the languages and file types we support and the files we ignore.

Check out our docs on how you can make Korbit work best for you and your team.

Loving Korbit!? Share us on LinkedIn Reddit and X

[mistercrunch]

LGTM . Wow, fix has been merged in 2021 ... maybe 1.1 will never happens.

[michael-s-molina]

@justinpark Won't decimal numbers be truncated in case they are passed to the native Javascript BigInt object? This can happen when value?.isGreaterThan?.(Number.MAX_SAFE_INTEGER) || value?.isLessThan?.(Number.MIN_SAFE_INTEGER). In other words, do we need to include a check for type integer?

if (
   value?.isInteger?.()  <-- check for integer
   value?.isGreaterThan?.(Number.MAX_SAFE_INTEGER) ||
   value?.isLessThan?.(Number.MIN_SAFE_INTEGER)
) {
   return BigInt(value);
}

Also, if that's the case, don't we also need to handle large decimals given that toNumber will truncate?

[justinpark]

Adding an integer check to BigInt is a good idea. I have added that part.

I think the truncation of large decimals is a trade-off. For example, when a value used as bigint is truncated, it affects the accuracy of the information related to the ID, so it is appropriate to keep all decimals by bigint format. However, in the case of large decimal floating numbers, since the values are within a range that allows arithmetic operations, I believe it is a part that can be compromised to support operations in such cases, even if some decimal can be truncated.