Implicit column aliases (no AS keyword) are rejected; differential harness misses it
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 78/100
Línea de trabajo
Start with the SELECT projection parser described in the issue, then inspect tests/fuzz-native-sqlite-differential.php and its aliases category. Reproduce the implicit-alias cases for plain columns and expressions, update coverage for both alias spellings, and verify that the parser matches MySQL and SQLite without regressing the existing differential cases.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
mdi-native rejects column aliases written without the AS keyword. MySQL and SQLite both accept them, and the form is common in WordPress and plugin code.
The failure is not specific to aggregates or to a table class — it is purely the alias syntax.
Reproduction
Identical query, three spellings:
$wpdb->get_results( "SELECT COUNT(*) FROM `wp_datamachine_jobs`" );
// OK [{"COUNT(*)":"1161"}]
$wpdb->get_results( "SELECT COUNT(*) AS n FROM `wp_datamachine_jobs`" );
// OK [{"n":"1161"}]
$wpdb->get_results( "SELECT COUNT(*) n FROM `wp_datamachine_jobs`" );
// ERR "mdi-native supports bounded single-table SELECT queries only."
Plain columns fail the same way:
$wpdb->get_results( "SELECT post_author au FROM wp_posts LIMIT 2" );
// ERR
Everything else has parity
With AS supplied, the same shapes all succeed against both core and generic tables:
| Query | Result |
|---|---|
SELECT status AS s, COUNT(*) AS n FROM jobs GROUP BY status |
13 rows |
SELECT COUNT(*) AS n, MIN(created_at) AS a, MAX(created_at) AS b FROM jobs |
1 row |
SELECT post_author AS au, COUNT(*) AS n FROM wp_posts WHERE post_type='wiki' GROUP BY post_author |
2 rows |
SELECT COUNT(*) AS n, MIN(post_date) AS f, MAX(post_date) AS l FROM wp_posts WHERE … |
1 row |
SELECT DATE(post_date) AS d, COUNT(*) AS n FROM wp_posts … GROUP BY DATE(post_date) LIMIT 3 |
3 rows |
So aggregates, GROUP BY, scalar functions in GROUP BY, and multi-aggregate projections are all supported. Only the alias spelling differs.
Why the differential harness misses it
tests/fuzz-native-sqlite-differential.php reports 256 cases, 32 categories, 0 mismatches — including an aliases category with 8 cases. It passes because every alias case appears to use the explicit AS form. A single implicit-alias case per category would have caught this.
This is worth fixing in the harness as much as in the parser: a differential suite that reports full parity while a common idiom fails in production is reporting on its own coverage rather than on parity.
Impact
The error message is also misleading. "supports bounded single-table SELECT queries only" describes neither the problem nor the fix for a query that is already a bounded single-table SELECT. It sent me looking at aggregate support and table classes before the alias was visible.
Observed in the wild in this session: routine diagnostic queries of the form SELECT status, COUNT(*) n FROM … GROUP BY status silently returned zero rows, which reads as "no data" rather than "unsupported syntax". Before the fail-closed work in #413 these returned empty with no error at all, which is worse — a silent wrong answer.
Suggested fix
Accept the optional-AS alias form in the SELECT projection parser, for both plain columns and expressions, matching MySQL and SQLite. Add implicit-alias variants to the differential workload so the harness covers both spellings.
AI assistance disclosure: found by Anthropic's Claude in OpenCode, directed by me, while measuring native/SQLite parity after deploying v0.13.3. The differential harness was run in full (256/256 passing) and contrasted against live queries; each spelling above was executed and its verbatim result captured. I reviewed the evidence before filing.
- Lenguaje dominante
- PHP
- Estrellas
- 5
- Forks
- 1
- Merge medio
- 2 h 37 min
- PR fusionados (30 d)
- 80
Preparar el entorno
Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 Automattic/markdown-database-integration
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Automattic/markdown-database-integration#424 ·
Los mantenedores suelen responder en 1 día
-
Native scans use memory proportional to row count, and retired generations are never collectedAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Automattic/markdown-database-integration#415 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
Automattic/markdown-database-integration#414 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
Automattic/markdown-database-integration#401 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
Automattic/markdown-database-integration#377 ·
Los mantenedores suelen responder en 1 día
Todos los issues de Automattic/markdown-database-integration
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Awaiting Triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
WordPress/two-factor#1008 ·
Los mantenedores suelen responder en 1 día
-
sync-en
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día