Soporte Postgres de Drupal
Hasta ahora no me había encontrado con un proyecto en el que, por requisitos técnicos, tuviera que conectar necesariamente con una base de datos Postgres. La razón era que necesitaba hacer conexiones con dos bases de datos diferentes con el CMS Drupal y esto sólo puede hacerse si el sistema de gestión de BD es el mismo.
Resulta un poco decepcionante, después de pasar largo tiempo defendiendo y presumiendo de abstracción en la gestión de consultas de Drupal y del soporte multiplataforma, encontrarte con que la mitad de los módulos no han preparado su .install para que puedan crearse las tabalas, índices y secuencias necesarias para su funcionamiento sobre Postgres.
Suerte, que leyendo un poco más descubro el nuevo API (Schema API) que viene preparado en la versión 6, en el que no sólo se abstraen consultas, actualizaciones y demás, sino que además permite la creación de tablas de forma "unificada".
Una de cal y otra de arena. Mi recomendación es que no merece la pena pelearse con una base de datos y que si tienes que enfrentarte a un Postgres con Drupal valora el tiempo de crear índices y tablas a mano.
A continuación voy a explicar en qué consiste en fichero .install y cuáles son los geniales cambios que se han implementado en la v6 y posteriores.
El gestor de contenidos Drupal funciona, grosso modo, con ficheros llamados módulos (extensiones). Cada módulo es una funcionalidad en sí misma, uno que gestiona los usuarios, otros que gestiona los blogs, etc.
Los módulos que no vienen incorporados en el paquete básico funcionan exactamente igual que el resto y consisten. Todos consisten en al menos 3 ficheros:
- Un .module, con el código de la funcionalidad en sí
- Un .info, con información de su descripción, versión, nombre, paquete, etc.
- Un .install, con el código necesario para su instalación, actualización y desinstalación
Fichero .install
Cuando el módulo se activa por primera vez, Drupal consulta si existe un fichero de este tipo y ejecuta la función que en él existe:
nombreDelModulo_install()
El código que contiene esta función suele ser de la forma:
switch ($GLOBALS['db_type']) {case 'mysql':case 'mysqli'://...break;case 'pgsql'://..break;default:drupal_set_message(t('Unsupported database.'));}Donde se mira el tipo de base de datos que se ha indicado en la configuración y se ejecuta el código sql apropiado para ese sistema de gestión.
El problema es que los desarrolladores del módulo se olvidan de proporcionar el código para los dos casos (actualmente son las bases de datos que, se dice, tiene soporte). Un problema que los usuarios tampoco resolvemos porque no reportamos la necesidad cuando se encuentra.
La solución dada con el nuevo API me parece, sin embargo, acertadísima.
Schema API
El Schema Api proporciona, como he comentado, la facilidad para defininir estructuras abstractas de base de datos para, porteriormente, convertirlas según el lenguaje específico de cada sistema de gestión de contenidos.
Ahora, nuestro código se simplifica (incluso se queda en la mitad), ya que sólo tendremos llamar dentro de la función nombreDelModulo_install(), al hook_schema, es decir a nombreDelModulo_schema('tabla').
Esta función debe estar definida dentro del módulo, será un hook más y se parecerá a:
function nombreDelModulo_schema(){$schema['tabla'] = array( 'fields' = array( 'vid' = array( 'type' = 'int', 'not null' = TRUE,... ), ),);return $schema;}Más información http://api.drupal.org/api/group/schemaapi/6
