ScalaQuery: Un DSL para acceso a base de datos en Scala

La manera más básica o primitiva de interactuar con una base de datos en Java es por medio de JDBC. Esto por supuesto se puede hacer también en Scala, Groovy o cualquier otro lenguaje para la JVM, pero al usar JDBC se tiene que programar en estilo Java por la manera en que fue diseñado.

En Scala existe una alternativa interesante: ScalaQuery. Lo que esta biblioteca nos permite hacer es realizar queries con código Scala, con un margen de error mucho menor, ya que se aprovecha el tipado estático del lenguaje de una forma que incluso en Java no se hace con JDBC.

La mejor manera de ilustrar su uso es con un ejemplo sencillo. Supongamos que tenemos una tabla, definida así en SQL:

Esta tabla tiene columnas con los tipos más comunes, algunas aceptan nulos, otras no. En ScalaQuery lo primero que hay que hacer para poder realizar operaciones sobre esta tabla, es definirla, como un objeto. Y tenemos que ponerle los tipos de cada columna. Si están familiarizados con Hibernate, verán que esto tiene cierta similitud, pero a la vez es muy distinto:

Algunos puntos importantes de esta definición:

• Por la manera en que la clase Table está definida, el compilador arroja un error si el método   no incluye todas las columnas que se definieron en la declaración de la tabla (los tipos de la tupla al principio de la definición).
• Del mismo modo, si definimos una columna con un tipo distinto que en la declaración de la tabla, la proyección de * no tendrá los mismos tipos y el compilador arroja una error.
• Las columnas que aceptan nulos son de tipo Option[tipo] en vez de ser directamente del tipo de la columna. De esta manera se pueden manejar los valores nulos de manera más idiomática en el código.
• La columna que es llave primaria lo tiene indicado con una opción, esto le sirve a ScalaQuery cuando queremos hacer un UPDATE.

Cabe mencionar que ScalaQuery no es un ORM, al menos no del tipo de Hibernate. Cuando hagamos un query, obtendremos tuplas; no podemos indicar que queremos instancias de cierta clase.

Queries compilados

Una vez que tenemos la definición de la tabla, es donde viene la parte tan útil de ScalaQuery: Las consultas que hagamos en código, si compilan, podemos estar seguros que funcionarán, siempre y cuando la definición de la tabla en Scala corresponda con la tabla en la base de datos. Esto es muy bueno porque si bien al principio podemos tardarnos más de lo normal en hacer una consulta, por la curva de aprendizaje, el beneficio a mediano y largo plazo es que tendremos menos problemas en tiempo de ejecución por tipos de datos mal mapeados (ClassCastException), manejo de nulos (NullPointerException), consultas desactualizadas, etc.

La consulta más simple,  , se puede hacer de varias formas en Scala:

Hasta aquí, en q1, q2 y c1 tenemos los queries ya compilados como objetos listos para usarse, pero aún no se ejecuta nada. Podemos pedirles el SQL que van a generar, invocando  , pero para ejecutar uno de estos queries, necesitamos tener una sesión o una transacción abierta, y ejecutarlos ahí dentro. Para ello utilizamos un objeto Database, al cual le pedimos una sesión y le pasamos una función que recibe la sesión como parámetro y ejecutamos nuestras consultas. Esto es muy fácil con un closure. El Database lo podemos crear a partir de un DataSource de JDBC.

Hay varias maneras de ejecutar un query, dependiendo de lo que queremos hacer con los resultados.

A fin de cuentas, estamos haciendo acceso a base de datos con programación funcional.

Queries parametrizados

Al no estar escribiendo SQL y concatenándolo a mano, nos evitamos problemas como inyecciones de SQL. Las consultas con condiciones se definen de manera idiomática con el for de Scala, donde podemos poner al final las columnas que queremos devolver:

Nótese que estamos usando un operador especial  , en vez de simplemente  . Este operador está definido en las columnas de la tabla, para definir la equivalencia pero no realizarla en el momento en que se define sino hasta después cuando se ejecute el query. Lo anterior sería equivalente a usar un PreparedStatement con el SQL  . Como estamos buscando sobre la llave primaria, sabemos que podemos obtener un solo registro, como máximo; puede que no haya registro con la clave solicitada. Por lo tanto lo mejor será usar el método   del query; hay un   pero si no se encuentra al menos un registro, arroja una excepción, mientras que   devuelve un Option con la tupla si la encuentra:

Así que podemos utilizar el pattern matching de Scala de manera normal.

Modificar datos

ScalaQuery no solamente sirve para hacer consultas. Los datos que se obtienen también se pueden actualizar, utilizando el mismo query. Si quisiéramos convertir a mayúsculas los datos de la tupla que encontramos con este último query, podemos poner este código dentro del caso donde sí la encontramos (en el Some):

Para las inserciones, se invoca directamente el objeto que representa la tabla, pasando los datos a insertar. Hay una variante que permite insertar varias tuplas al mismo tiempo, usando el batch insert de JDBC.

Transacciones

Para cuando se requieren hacer varias operaciones en una sola transacción de base de datos, simplemente hay que utilizar   en vez de  :

Funcionalidad adicional

Esto es apenas una probadita de lo que puede hacer ScalaQuery. Además de todo esto, hay sintaxis para joins, para crear las tablas directamente desde ScalaQuery (para lo cual hay que definir varias cosas adicionales en cada columna, como su longitud, default, etc), etc.

Esta biblioteca sigue evolucionando; al momento de escribir esto, la versión es 0.9.5. El mayor problema que he tenido para utilizarla es que la documentación es algo escueta y no está muy actualizada, por ejemplo el API publicado es para la versión 0.9.4, no hay de la 0.9.5; las guías de uso llevan bastante tiempo sin actualizarse y algunas cosas ya no son como dice la documentación porque ha habido cambios de sintaxis y cosas así.

En fin, esta es una opción más para manejar el acceso a bases de datos en Scala. Otra opción es Squeryl, que tiene una filosofía similar de aprovechar el tipado estático para construir queries que se validan mayormente en la fase de compilación, sin embargo parece ser un ORM más en forma, lo cual tiene sus propias ventajas y desventajas.