Tengo un controlador que genera consultas dinámicas y las busca con
find_by_sql. Es decir, que pasando por el mismo controlador, puede pasar
la
consutlta select login from usuarios y select login, password from
usuarios.
El caso es que para dibujar la tabla de resultados, en caso de que la
consulta haya devuelto más de un resultado, se recorren las claves del
hash
devuelto en el primer resultado asÃ:
Ahí ando un poco perdido. ¿Cómo lo utilizaría? porque el método
find_by_sql rellena el @attributes del modelo, que es un hash.
¿Tendría que sobreescribir la clase Hash? ¿Cómo se haría?
A riesgo de parecer tonto… es necesario el segundo bucle?
Por que no en vez de esto:
<%if @items.size==0% >
No hay elementos
<%end%>
<% @items.each do |objeto| %>
<tr class=“record <%= cycle(”",“even-record”) %>">
<%for columna in @columnas%>
No, las consultas las mete el administrador en un text area y la
aplicación
se encarga de añadirle las condiciones y tal. Pero es el administrador
el
que mete el código sql tal cual.
Luis V.
escribió:> Es porque las consultas las genera una persona. Igual puede poner select
perros from usuarios que select casas from usuarios, así que de antemano
yo no voy a saber qué columnas son las que van a salir.
Las consultas se generan al vuelo? Es decir, tú das en tu interfaz la
opción de indicar qué columnas se desean consultar? En ese caso podrías
almacenar esas columnas en una SequencedHash @columnas, generar a partir
de ella la consulta y utilizarla en la vista para determinar el orden en
que se muestran los datos.
No, las consultas las mete el administrador en un text area y la
aplicación se encarga de añadirle las condiciones y tal. Pero es el
administrador el que mete el código sql tal cual.
Es como un generador de reportes (más o menos)
yo una vez tuve que hacer algo parecido… un generador en el que el
usuario podía meter la consulta en la aplicación y le generaba un excel
con la respuesta, y lo que acabé haciendo fue una solución más o menos
simple. Tomaba el sql que me pedían lanzar, me quedaba con el texto que
aparecía entre “SELECT y FROM” y ese texto lo separaba por comas para
saber cuáles eran las columnas que me pedían.
Como sabes, en una select se pueden meter muchas filigranas, funciones
agregadas, claúsulas AS, etc… Si quieres hacer un parser capaz de
tragarse todo eso y que además sea multidb, suerte… yo consulté con mi
usuario para saber qué tipo de selects iban a usar y poder así parsear
la lista de columnas. Si las selects van a ser sencillas, lo mismo te
vale con separar por comas, comprobar si hay un AS y si no directamente
tomar el nombre de la columna.
Una vez parseadas, me guardaba en un array el nombre de las columnas. Y
ya para cada fila, iteraba sobre ese array para ir recogiendo en order
los resultados.
Para asegurar que funcionaba bien incluso cuando no conseguía parsear,
en el caso de no poder parsear las columnas directamente creaba un array
a partir de los atributos resultantes en la consulta. En ese caso las
columnas del resultado no aparecían en el orden introducido, pero no
está mal ya que el usuario tampoco había introducido una select conforme
a lo acordado.