Proposal for sqlparser-rs 2.0
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 15/100
- Tipo de issue
- Refactorización
- Claridad
- Necesita aclaración
- Estado de actividad
- Activo
- Stack tecnológico
- rust
- Área
- backend-api-design, databases
Línea de trabajo
The proposal describes a broad sqlparser-rs 2.0 redesign, but names no files, tests, or entry points to start from. Read the issue thread to understand the community’s response and the proposed design; the goal would be a decided path for the 2.0 work, with parity against v1 and the described correctness fixes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Over the weekend, I started from a clean slate and implemented a new version of the sqlparser-rs crate using the design that I had originally wanted but did not know how to build (I was still quite new to Rust at the time).
The new version has one trait per dialect and all dialect-specific parsing lives in that trait. There is no longer one huge "core" parser containing conditional logic for different dialects. Related dialects can also share logic. For example, the Hive and Databricks dialects both call into the Spark dialect for common pieces.
The new version also has ~10x fewer memory allocations (no more copying Strings everywhere) and is ~10x faster.
I am nearly finished porting all of the existing dialects over. The actual parsing code is taken from the current implementation, so that is not re-written. I have ported over all the tests as well, and am working towards 100% parity with v1, although v2 contains quite a lot of correctness fixes compared to v1.
What is the appetite in the community for me pushing this to a new 2.0 branch in the Apache repo?
Another option would be for me to file a huge issue explaining the design in detail, and let the community rebuild it.
WDYT?
- Lenguaje dominante
- Rust
- Estrellas
- 3.5k
- Forks
- 805
- Merge medio
- 2 d 3 h
- PR fusionados (30 d)
- 116
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin 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 apache/datafusion-sqlparser-rs
-
Redshift
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
apache/datafusion-sqlparser-rs#2959 ·
Los mantenedores suelen responder en 1 día
-
Redshift
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
apache/datafusion-sqlparser-rs#2958 ·
Los mantenedores suelen responder en 1 día
-
PostgreSQL
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
apache/datafusion-sqlparser-rs#2862 ·
Los mantenedores suelen responder en 1 día
-
PostgreSQL
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
apache/datafusion-sqlparser-rs#2861 ·
Los mantenedores suelen responder en 1 día
-
PostgreSQL
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
apache/datafusion-sqlparser-rs#2858 ·
Los mantenedores suelen responder en 1 día
Todos los issues de apache/datafusion-sqlparser-rs
Issues similares
-
area:schema documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
ElectronicWave/Elemental#252 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dekobon/big-code-analysis#1887 ·
Los mantenedores suelen responder en 1 día
-
Shell中文符号输入异常Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día