SQL system data type synonym name lost and replaced during parsing
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
Línea de trabajo
Comienza reproduciendo los ejemplos de NATIONAL CHARACTER VARYING y DOUBLE PRECISION, e inspecciona DatatypeReference.Name.BaseName junto con SqlDataTypeOption. Determina dónde el análisis reemplaza o descarta el sinónimo proporcionado; el trabajo estará terminado cuando el AST conserve cada nombre de tipo de datos original y mantenga la información de tipo normalizada del analizador.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- GAP
- Estrellas
- 277
- Forks
- 43
- Merge medio
- 6 d 17 h
- PR fusionados (30 d)
- 3
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/SqlScriptDOM
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
microsoft/SqlScriptDOM#228 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
microsoft/SqlScriptDOM#183 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 56/100
microsoft/SqlScriptDOM#226 · 1 reacción ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
microsoft/SqlScriptDOM#225 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
microsoft/SqlScriptDOM#224 ·
Todos los issues de microsoft/SqlScriptDOM
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
internal.h中,漏掉了1个定义。 Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
oxc-project/oxc#26944 ·