Capítulo 5. La librería cliente Gda

Tabla de contenidos
Introducción
Presentación de los objetos Gda
Tipos de datos
Meta-datos de las fuentes de datos
Trabajos en modo batch
Referencia de funciones

Introducción

La librería cliente es una fina capa alrededor de la interfaz Corba. La capa se ocupa de la reserva y devolución de memoria cuando ya no necesite mas los resultados de una consulta, o cuando cierre la conexión a la base de datos. Su segundo propósito es disponer de un tampón ("cache"), para que sea posible desplazarse hacia delante y hacia atrás dentro de una consulta, aun si la base de datos no soporte este tipo de deslizamiento en el cursor. Por supuesto no se soportara las estrategias de consistencia y bloqueo de la base de datos en estos accesos, pero pienso que encontrare una solución para esto.

Se dispone también de soporte para manejar diferentes fuentes de datos con diferentes servidores y características de conexión. Para conseguir este objetivo se leen varios ficheros de configuración en el directorio inicial del usuario (no hay soporte para configuraciones globales todavía). El programa gda-manager puede usarse para visualizar estos ficheros y editar su contenido.

También contiene funciones utilidad para ayudarle a afrontar diferentes tareas relacionadas con las bases de datos. Esto incluye ejecución de comandos en modo "batch" (transacciones), acceso a proveedores Gda, configuración de acceso por medio del sistema de "plug-in" de gda-manager, ...

El principal concepto de la librería cliente es que el proveedor le permite conectarse a varias fuentes de información. Este proveedor es un servidor Corba implementado con Orbit. Un proveedor proporciona una factoría de interfaces que permiten al cliente solicitar conexiones no inicializadas al proveedor. La activación del proveedor se realiza a través del la librería Gnorba. Esta librería gestiona la identificación por el servidor de nombres Gnome y el registro del servidor Corba (el proveedor Gda), una vez que esta activo. Gnorba también permite al cliente elegir, si para cada instancia de la factoría se debe arrancar un nuevo servidor, o si se debería usar un servidor ya en ejecución. Este tiene repercusiones en el tiempo de arranque usado y en el numero de procesos conectados al servidor de base de datos ( y por tanto al numero de licencias usado).

Con el fin de conseguir una conexión a una fuente de datos, el cliente debe usualmente proporcionar cierta información al proveedor. En primer lugar debe proporcionar el nombre de la fuente de datos al proveedor. El proveedor usa entonces este nombre en su modo especifico para localizar las partes desconocidas necesarias para establecer una conexión con el autentico servidor de datos. Esto puede ser un nombre de maquina y un numero de puerto, el nombre de una librería compartida que deba cargarse, o cualquier cosa que se necesite para acceder el sistema de base de datos o la fuente de datos. Adicionalmente el cliente debe suministrar un nombre de usuario y una clave para ser autenticados por el servidor de base de datos. El propio proveedor no realiza ningún tipo de pruebas de autenticación. Observe también que la conexión con el cliente no esta encriptada, así que los datos se mandan en claro. Esto cambiara cuando Orbit soporte comunicaciones encriptadas entre el servidor Corba y sus clientes. Si esta circunstancia no es aceptable, use el proveedor como librería compartida.

Una vez que la conexión haya sido abierta, el cliente puede solicitar información de diccionarios de datos a la fuente de datos. La semántica de los datos devueltos por estas peticiones esta muy ligada al proveedor y normalmente no se puede migrar de una fuente de datos a otra. Si el proveedor pertenece a la misma clase (base de datos por ejemplo), esta información podrá ser intercambiable, pero no espere que un mismo programa cliente interrogue a un proveedor Ldap o a un proveedor Odbc sin cambios en el código fuente del cliente.

El cliente puede entonces crear objetos Gda_commands que se usaran para realizar las verdaderas consultas a los proveedores. Para los proveedores Obdc y Mysql la consulta es la misma sentencia Sql. Por supuesto el proveedor es libre de cambiar las sentencias (conversión entre dialectos Sql) y algunos proveedores pueden incluso especificar su propio lenguaje (el proveedor Ldap haría esto). Es también posible llamar a procedimientos almacenados. Estos procedimientos pueden guardarse en el servidor (el sistema de base de datos) o pueden estar implementados por el proveedor. Otra posibilidad es enviar únicamente el nombre de una tabla al proveedor. El proveedor devolverá todas las filas y columnas de la tabla al cliente.

El resultado de una consulta se accede a través de un objeto de tipo Gda_Recorset. Los registros de datos actuales pueden almacenarse en el lado del cliente, el lado del servidor o en el servidor de base de datos. Esto depende de varios indicadores y opciones usados cuando se crea el juego de registros. Las posiciones en el juego de registros se definen a través de señaladores, que son tipos de datos ocultos. Un señalador puede usarse para situar el puntero actual de acceso en el juego de registros. Debido a que algunos sistemas de bases de datos no permiten situar de forma arbitraria el puntero de acceso en el conjunto de registros de una consulta, el proveedor almacena y "cachea" todos los registros de datos recibidos. Si el conjunto de registros esta configurado para almacenar los datos en el lado del cliente, entonces el señalador es simplemente un puntero a los registros. Puede leer mas acerca de como almacenar registros de datos, la cache y las transacciones en la sección dedicada al los conjuntos de registros.