SQL system data type synonym name lost and replaced during parsing
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 42/100
Piste de recherche
Commencez par reproduire les exemples NATIONAL CHARACTER VARYING et DOUBLE PRECISION, puis examinez DatatypeReference.Name.BaseName avec SqlDataTypeOption. Déterminez où l’analyse remplace ou supprime le synonyme fourni ; le travail est terminé lorsque l’AST préserve chaque nom de type de données d’origine tout en conservant les informations de type normalisées de l’analyseur.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
ScriptDom version: 161.9142.1
Compatibility level: 150
While trying to implement custom TSQL linter rule which should prevent developers from using non-conventional data type names (synonyms) I've faced an issue: ScriptDom modifies type name during parsing. Which makes detection of synonym usage impossible or hard to implement.
For example:
DECLARE
@a NATIONAL CHARACTER VARYING (100)
, @b DOUBLE PRECISION
, @c INTEGER
Here only "INTEGER" synonym (for INT data type) can be easily detected. Data type name for @a is delivered to DatatypeReference.Name.BaseName partially: it contains CHARACTER word only. Yes, "character" is a synonym as well, but not the one that was actually provided.
Moreover, DOUBLE PRECISION gets lost totally: DatatypeReference.Name.BaseName.Value here comes as Float. It's good to know that the parser knows what is what but actual script contents disappeared after parsing - IMHO this is no good.
I'd expect ScriptDom parser to keep what was provided - a full original data type name no matter if it was a UDT or registered sql-server supplied type synonym. As far as I can understand ScriptDom has SqlDataTypeOption for internal needs and this DatatypeReference's property does contain NVarChar and Float as expected for both of mentioned examples above. Seems like BaseName could keep the original type name.
- Langage dominant
- GAP
- Étoiles
- 277
- Forks
- 43
- Merge moyen
- 6 j 17 h
- PR mergées (30 j)
- 3
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de microsoft/SqlScriptDOM
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
microsoft/SqlScriptDOM#228 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
microsoft/SqlScriptDOM#183 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 56/100
microsoft/SqlScriptDOM#226 · 1 réaction ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
microsoft/SqlScriptDOM#225 ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 58/100
microsoft/SqlScriptDOM#224 ·
Toutes les issues de microsoft/SqlScriptDOM
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
JakeChampion/lang#10213 ·
-
bug language-server
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
purefunctor/purescript-iris#552 ·
-
enhancement good first issue needs testing
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
bradcypert/plum#58 ·