fix(sqllab): clean comments within quotes

[justinpark]

SUMMARY

minor regression from #23378

The regex for commented out block also clean up the block within the quotes.
Therefore following query threw a syntax error since it removes the quoted value.

SELECT * FROM table WHERE column = '--unknown--';
==> 
SELECT * FROM table WHERE column = '

This commit adds the condition to skip the quoted block.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

After:

SELECT * FROM table WHERE column = '--unknown--';
==> 
SELECT * FROM table WHERE column = '--unknown--';

Before:

SELECT * FROM table WHERE column = '--unknown--';
==> 
SELECT * FROM table WHERE column = '

TESTING INSTRUCTIONS

Added tests for edge cases

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

[codecov]

Codecov Report

Merging #23908 (f9f1118) into master (594d3e0) will increase coverage by 0.00%.
The diff coverage is 79.04%.

❗ Current head f9f1118 differs from pull request most recent head 0d1cc15. Consider uploading reports for the commit 0d1cc15 to get more accurate results

@@           Coverage Diff           @@
##           master   #23908   +/-   ##
=======================================
  Coverage   68.11%   68.12%           
=======================================
  Files        1938     1940    +2     
  Lines       74972    75048   +76     
  Branches     8141     8155   +14     
=======================================
+ Hits        51067    51124   +57     
- Misses      21826    21841   +15     
- Partials     2079     2083    +4     

Flag	Coverage Δ
javascript	54.49% <69.56%> (+0.02%)	⬆️

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

Impacted Files	Coverage Δ
...s/legacy-plugin-chart-calendar/src/controlPanel.ts	50.00% <ø> (ø)
...rts/src/BigNumber/BigNumberTotal/transformProps.ts	0.00% <0.00%> (ø)
...lugin-chart-echarts/src/BigNumber/BigNumberViz.tsx	0.00% <0.00%> (ø)
...set-frontend/src/components/Select/AsyncSelect.tsx	88.46% <ø> (ø)
superset-frontend/src/components/Select/Select.tsx	90.41% <ø> (ø)
...nd/src/explore/components/RunQueryButton/index.tsx	100.00% <ø> (ø)
...onalFormattingControl/FormattingPopoverContent.tsx	51.35% <ø> (ø)
superset-frontend/src/preamble.ts	0.00% <0.00%> (ø)
superset-frontend/src/setup/setupFormatters.ts	0.00% <ø> (ø)
superset-frontend/src/types/bootstrapTypes.ts	100.00% <ø> (ø)
... and 19 more

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[michael-s-molina]

LGTM but it would be nice to get @villebro and @betodealmeida approvals too.

[ktmud]

Interesting approach

[ktmud]

Suggested change

	.replace(/(--.*?$|\/\*[\s\S]*?\*\/)\n?/gm, '\n')
	.replace(/(--.*$|\/\*[\s\S]*\*\/)\n?/gm, '\n')

I don't think these question marks are necessary

[justinpark]

This ? mark covers the multiple comment group case

i.e.

/*
comments
*/
no-comments
/*
comments
*/

.replace(/(--.?$|/*[\s\S]?*/)\n?/gm, '\n') => no-comments
.replace(/(--.$|/*[\s\S]*/)\n?/gm, '\n') => '\n'

[villebro]

@justinpark @michael-s-molina @ktmud we have a fair deal of logic for this in the backend - is there some reason we want to parse for this kind of stuff in the frontend? It feels like we should centralize this in one place.

[michael-s-molina]

@justinpark @michael-s-molina @ktmud we have a fair deal of logic for this in the backend - is there some reason we want to parse for this kind of stuff in the frontend? It feels like we should centralize this in one place.

I didn't know about that @villebro. Could you point to the code? I agree that if there's no reason for doing it in the frontend, we should centralize it in the backend.

[ktmud]

I agree this logic is probably better to live in the backend---it's more useful to record the original SQL users wrote, too.

Not sure how comments are removed in the backend but my guess is it happens after we render the Jinja template (which is why we saw the error in #23378 in the first place).

Maybe we can change it to remove comments before rendering, but how would you know the comments are safe to remove without rendering the template? Also, if we are removing comments using a SQL parser, the parser is likely to fail before you render the template. Not sure what's the best way forward, but since we are already removing comments in the frontend, it's probably still worth merging this PR first.

[justinpark]

Maybe we can change it to remove comments before rendering, but how would you know the comments are safe to remove without rendering the template? Also, if we are removing comments using a SQL parser, the parser is likely to fail before you render the template. Not sure what's the best way forward, but since we are already removing comments in the frontend, it's probably still worth merging this PR first.

I agree with ktmud's idea

[villebro]

@ktmud @justinpark I agree, this is an improvement to the status quo; we can follow up later by moving this into the backend. @michael-s-molina you can check superset/sql_parse.py which we use for parsing queries in the backend, and I seem to recall having added tests that ensure '--comment' aren't stripped out, which is very similar to what's being checked here.

[justinpark]

I agree, this is an improvement to the status quo; we can follow up later by moving this into the backend.

Sounds good. yeah definitely backend is a better place. until then, we can use this solution