Repository navigation
Provide an option in the SqlNNNScriptGenerator classes to preserve comments #20
Description
Activity
Would really appreciate if this issue was fixed, it will help greatly with using scriptdom to fix code issues. thank you.
This fix would be a huge help! Not only for me but many others. Thank you.
Completely agree that we need an option to preserve comments when using the script generator.
Just in case someone wants to tackle this the filtering seems to occur here.
SqlScriptDOM/SqlScriptDom/Parser/TSql/TSqlTokenFilter.cs
Lines 40 to 43 in 714ef04
The only place I found
TSqlTokenFiltercalled was SqlScriptDom/Parser/TSql/TSql80ParserBaseInternal.cs which is inherited by all the other Parsers so this seems to go deeper than ScriptGenerator options.EDIT: I guess if ScriptGenerator controls the creation of the parser an option could be created for TsqlNNNParser but I can't figure out where that class is getting called.
So this
-- This is a comment SELECT * FROM mytable
results in
$Results.ParsedObjects.Batches[0].ScriptTokenStream[0] // Value: SingleLineComment $Results.ParsedObjects.Batches[0].ScriptTokenStream[1] // Value: Whitespace Newline $Results.ParsedObjects.Batches[0].ScriptTokenStream[2] // Value: SELECT $Results.ParsedObjects.Batches[0].FirstTokenIndex // Value: 2
Comments would need to be excluded from semicolon adding and it might cause some tests to fail if they aren't expecting comments.
Fiddled around with Token rewriting but unlike Arvind I didn't have any luck. Modifying
TokenTypeorTextonScriptTokenStreamtokens and passing them into the Generator produced the same result.TsqlFragement.Batches[0].Statements[0].Expression.Valuecan change some part of the statement but not the keyword.UpdateTokenInfomethods are internal.Reacted by Jerry Nixon and Christian KlutzWithout this, most ScriptDom use cases are dead in the water.
Reacted by Christian Klutz, Daniel Hamilton, Mark Ridgwell, Chris Smith, MrMikeJJ and JefftWow! It's been almost 4 years and this issue still hasn't been fixed?
This causes all tools relying on this SQL...ScriptGenerator to become useless !! ( e.g. SqlFormatter )
Devs have put so much effort to (finally) put comments in their code, and now that is being removed by your component
This needs to be fixed, as now SqlFormatter is added as an extension to SSMS 21!
Reacted by Adhemar, Jefft and MarkFreemanBDORemoving comments from code....absolutely the worst possible action to take. Code without comments can become useless to maintain.
Reacted by MarkFreemanBDO and Vlad DrumeaEchoing ALZDBA's comment. If this is to be used by any tool for displaying sql to users, comments are the worst thing to remove.
Reacted by MarkFreemanBDOMake sure to upvote/like the initial issue here
I would like to second everyone here.
I think that's one of the top voted features.
Can this be prioritized?Reacted by Adhemar
Is your feature request related to a problem? Please describe.
Some use cases for the Sql*ScriptGenerator classes are actually for code "pretty printing" / formatting. However, using Sql150ScriptGenerator to re-generate the SQL text when provided with an input TSqlFragment, leads to comments (single-line and multi-line) both being excluded from the output.
Describe the solution you'd like
Provide an
PreserveCommentsproperty inSqlScriptGeneratorOptionswith the default beingtruein the 160 version, andfalsein the 150 or lower versions for backward compat.Describe alternatives you've considered
Token re-writing: substituting a faux
printstatement instead of the comment token is a crude workaround. It fails in case the comment is a trailing suffix of a line within a multi-line T-SQL statement.