DDL Statement vs Select statement identical results
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- sql, typescript
- Área
- backend-api-design, databases
Línea de trabajo
Comienza con el flujo de DBSQLClient session.executeStatement y las APIs query.fetchChunk(), query.hasMoreRows() y query.metadata.schema mostradas en el informe. Compara cómo se exponen las operaciones CREATE TABLE y SELECT vacío, y determina después si los metadatos pueden distinguirlas o si es apropiado cambiar la fila de resultados. Se considera terminado cuando los llamadores pueden identificar la operación de forma fiable sin analizar SQL.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hello,
After testing, it appears that the results of the following 2 queries are indistinguishable when looking at the result sets:
CREATE TABLE example (
col1 INT
);
and
SELECT 'sample' as Result
WHERE 1 = 0;
This is because when iterating over the rows, both return 0 rows:
import { DBSQLClient } from '@databricks/sql';
const connectionOptions = {...};
let results = [];
const client = new DBSQLClient();
const session = await client.connect(connectOptions);
const query = await session.executeStatement(query, options);
do {
results = results.concat(await query.fetchChunk());
} while (await query.hasMoreRows());
console.log(results);
And the schema is exactly the same:
... code above
console.log(query.metadata.schema)
Do you have any advice for differentiating the operations without requiring in a SQL parser to determine the query? Would it be possible to add the operation type to the query.metadata, or a result row for DDL operations?
- Lenguaje dominante
- TypeScript
- Estrellas
- 36
- Forks
- 50
- Merge medio
- 13 h 46 min
- PR fusionados (30 d)
- 9
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 databricks/databricks-sql-nodejs
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Docs folder deleted in 1.8.4 Abiertoengineer-bot
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
databricks/databricks-sql-nodejs#274 · 1 comentario · 1 reacción ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Todos los issues de databricks/databricks-sql-nodejs
Issues similares
-
S: triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
snapshot-labs/stamp#666 ·
-
fix(api): prevent leaderboard SSE heartbeat from starting after disconnect during initial load Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
GauravKarakoti/SecureFlow#1070 · 1 comentario ·
-
feature:Languages/Translations good first issue ready Web
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
digitalfabrik/integreat-app#4394 ·