Me gustaría una función genérica que convierta el resultado de una consulta SQL a JSON. Me gustaría construir una cadena JSON manualmente (o usar una biblioteca externa). Para que eso suceda, necesito poder enumerar las columnas en una fila dinámicamente.
let rows = client .query("select * from ExampleTable;") .await?; // This is how you read a string if you know the first column is a string type. let thisValue: &str = rows[0].get(0);Los tipos dinámicos son posibles con Rust , pero no con la API de la biblioteca tokio-postgres.
La función row.get de tokio-postgres está diseñada para requerir una inferencia genérica de acuerdo con el código fuente
Sin la API correcta, ¿cómo puedo enumerar filas y columnas?
Debe enumerar las filas y las columnas, al hacerlo, puede obtener la referencia de la columna mientras enumera, y de ahí obtener el tipo postgresql. Con la información de tipo es posible tener una lógica condicional para elegir diferentes subfunciones para ambos: i) obtener la variable fuertemente tipada; y, ii) convertir a un valor JSON.
for (rowIndex, row) in rows.iter().enumerate() { for (colIndex, column) in row.columns().iter().enumerate() { let colType: string = col.type_().to_string(); if colType == "int4" { //i32 let value: i32 = row.get(colIndex); return value.to_string(); } else if colType == "text" { let value: &str = row.get(colIndex); return value; //TODO: escape characters } //TODO: more type support else { //TODO: raise error } } }Consejos extra para mantenedores de código tokio-postgres
Idealmente, tokio-postgres incluiría una API directa que devuelva un dyn any tipo. Las partes internas de row.rs ya utilizan la información del tipo de columna de la base de datos para confirmar que el tipo genérico proporcionado es válido. Idealmente, una nueva API usaría la información de la columna interna de manera bastante directa con la API FromSQL mejorada, pero existe un término medio más simple:
Sería posible que una capa de función adicional en row.rs use la misma lógica condicional de tipo de columna que se usa en esta respuesta para luego aprovechar la función get existente. Si un usuario como yo necesita manejar este tipo de lógica condicional, también necesito mantener este código cuando tokio-postgresql maneja nuevos tipos, por lo tanto, este tipo de lógica debe incluirse dentro de la biblioteca donde dicha funcionalidad puede ser mejor mantenido