pedels, desde la amígdala

Por necesidades de mi PFC he tenido que buscarme un parser de SQL para Java y quiero ahorrarle al resto del mundo tan tediosa tarea.

Podría parecer que un parser SQL para Java es una cosa poco exótica (bueno, depende de dónde te muevas, probablemente para la mayor parte de la gente lo sea :P) pero no hay una solución que podríamos considerar ampliamente aceptada. En lugar de eso podemos encontrar múltiples soluciones parciales más o menos incomodas.

Podemos resumir que todo fue un poco infernal hasta que me decidí a probar JSqlParser, un parser de Sql para Java basado en una gramática para JavaCC creada por un tal Guido Draheim. Yo hasta hace poco tampoco entendía nada de esto :)

En un artículo posterior profundizaremos en JSqlParser. En este articulo se comentan las posibilidades que existen y la dificultan que conllevan, así como algunos conceptos sobre parsers, gramáticas y trabajo innecesario: ¿quieres saber más? pues sigue leyendo:

En realidad tenemos múltiples opciones, que vamos a ir recorriendo de mayor a menor dificultad:

Puedes programar tu propio parser desde cero. Si no estás metido en lingüistica Computacional y sabes de que estás hablando, mejor que descartemos esta opción.

Una propuesta que se puede encontrar facilmente es: “Puedes hacerte tu propio parser utilizando una generador como JavaCC , ANTLR o LPG“. Bueno, la expresión equivalente podría ser algo como: “Si quieres ir al trabajo comodamente puedes construirte tu propia bicicleta con cualquier caja de herramientas”.

Los generadores de parser son complejos y si el parser no es algún aspecto central de tu tarea, no creo que valga la pena aprender. Estas herramientas funcionan del siguiente modo: una persona escribe un conjunto de reglas (normalmente llamadas gramática) y el generador, usando estas reglas, da como salida código en un lenguaje de programación concreto que permite parsear(permitidme la licencia, “analizar sintácticamente” es mucho más largo) el lenguaje de programación deseado. El lenguage de salida puede ser definido mediante la gramatica (como en ANTLR) o estar definido de antemano (como en JavaCC). Si os gustan los compiladores y teneis mucho tiempo libre, ¡adelante!. En otro caso, seguid leyendo.

Una opción más moderada es buscar una gramática que alguién haya creado ya y utilizar el generador de parsers para crear nuestra ansiada herramienta. Esta opción me pareció muy interesante al principio, pero encontramos dos problemas:

1. Encontrar la gramatica: no estan fácil encontrar una gramática completa para SQL estándar. Encontramos múltiples para subconjuntos o implementaciones concretas pero la gran gramática que buscamos es esquiva y se oculta bien.
2. El parser generado no es precisamente user friendly. De repente tendrás entre tus manos un maremagnum de clases y métodos y ninguna idea de como meterle mano (ni documentación, dicho sea de paso).

Como ejemplo mi experiencia, encontré una referencia (que no localizo ahora) acerca del parser de SQL que Derby usa internamente. Bien, destripé a Derby, extraje la gramática para JavaCC que contiene y generé el parser: el infierno es más sencillo de controlar. Huelga decir que, después de eso, destripar un plugin de SQuirreL no era una posibilidad.

Como tercera opción tenemos usar un parser completito, existente y, a ser posible, con una licencia generosa. Encontramos unos cuantos en la busqueda:

• ZQL: basado en un parser generado con JavaCC. Descartado por su falta de garantías y porque la batería “exhaustiva” de pruebas que muestra deja mucho que desear.
• SQL4J: demasiado bonito para ser cierto, es sencillo y parece funcionar muy bien para la mayor parte de los casos. Perdió su oportunidad cuando se atascó en un caso sencillo y habitual como el de encontrar una función como SUM(tabla.columna1) en la consulta. Esto sumado a la total falta de documentación provocaron su caída de la lista.
• sql development tools project dentro de Eclipse: basado en LPG, muy interesante si usas Eclipse pero no pude llegar a probarlo porque es incompatible con la versión que usamos en la empresa. Me quede con las ganas.

El último elemento de esta lista es el que titula este artículo: JSqlParser. Basado en un parser generado con JavaCC. Este parser asusta en un primer momento por su complejidad aparente (sobre todo si no has estudiado informatica o sabes bastante de POO como es mi caso) pero vale la pena el esfuerzo. Su curva de aprendizaje es un poco abrupta, lo que quiere decir que un pequeño esfuerzo inicial se ve compensado con un dominio más que suficiente de la herramienta en poco tiempo.
La documentación no es maravillosa pero sí aceptable y hay una cierta comunidad alrededor que puede dar respuestas.

Es útil tanto para analizar como para generar consultas SQL de una complejidad asombrosa, sin duda una gran opción y mi recomendación.

En el proximo artículo abordaremos un poco la estructura y la forma de trabajar de JSqlParser. Lo cual ahorrará a muchos el trabajo inicial de entender y empezar a trabajar con JSqlParser.