Aplicaciones de bases de datos con Kylix

Transcripción

1 Aplicaciones de bases de datos con Kylix Una de las novedades más importantes de Kylix será la aparición en escena de la arquitectura dbexpress o DBE, sustituto natural del Borland Database Engine o BDE. Esto ocasionará una serie de cambios muy importantes en la forma en que desarrollamos aplicaciones de bases de datos, y la tecnología MIDAS jugará un rol fundamental en estos cambios. Qué es Kylix? Introducción Kylix es la primera y única herramienta de desarrollo rápido de aplicaciones para el sistema operativo Linux. Kylix es Delphi y C++Builder para Linux. Los puntos más destacados de Kylix son: Desarrollo de aplicaciones nativas Linux. Entorno de desarrollo visual basado en componentes. Soporte para MySQL, InterBase, Oracle y DB2, para el desarrollo de aplicaciones de bases de datos cliente/servidor. Soporte de Apache, para el desarrollo de aplicaciones para Internet. Combinado con Delphi, Kylix permite el desarrollo de aplicaciones multiplataforma para Windows y Linux. Kylix está certificado para RedHat Linux 6.2 ó superior, Mandrake 7.0 ó superior y SuSE 7.0 ó superior. Antes de comenzar, creo que es importante aclarar algo: el BDE no desaparecerá; al menos, no en Delphi 6. Seguirá existio tal y como hasta ahora, y aunque Borland no liberará nuevas versiones, seguirá brindando soporte como de costumbre. Un poco de historia Por mucho tiempo, el BDE fue una solución excelente para el desarrollo de aplicaciones de bases de datos, sobre todo a la hora de acceder a tablas locales. Sin embargo, a medida que la tecnología cliente/servidor se hizo más popular, el BDE poco a poco dejó de ser lo que era para convertirse en una solución buena con limitaciones funcionales y problemas de rimiento. Cuando el proyecto Kylix se hizo realidad, los ingenieros de Borland se vieron obligados a tomar una decisión crucial: elegir entre migrar el BDE a Linux con todas sus limitaciones y problemas o aprovechar la oportunidad para desarrollar algo nuevo, más potente que el BDE, portable y, lo más importante, orientado a servidores SQL. La decisión no fue muy difícil de tomar, y así surgió dbexpress. Tanto Kylix como Delphi 6 incluirán DBE como una nueva alternativa de acceso a datos. Esto significa que a las tres alternativas ya existentes en Delphi 5, se sumará una: los componentes basados en DBE. Este cambio no será difícil de asimilar por los programadores Delphi, ya que es algo muy parecido a lo que ya ocurrió con Delphi 5, y de la misma forma que los componentes de acceso nativo a ADO e InterBase incluyen equivalentes a los basados en el BDE - lo cual, dicho sea de paso, facilitó mucho su

2 utilización en nuevos proyectos -, los componentes basados en DBE también trán sus equivalentes a los basados en el BDE. Por lo tanto, en Delphi 6 habrá 4 alternativas diferentes de acceso a datos, de las cuales sólo una (DBE) permitirá la creación de proyectos multiplataforma, que podrán ser portados de Windows a Linux o de Linux a Windows directamente. Me caching los datos Si bien la aparición de nuevos componentes constituye un cambio importante en sí mismo, este no será el más importante que tremos que afrontar. La gran novedad estará dada por el hecho de que DBE no soportará caching de datos. Qué significa esto? Veamos un ejemplo que nos ayude a comprerlo. Creemos un formulario que nos permita visualizar en una rejilla los datos de la tabla Country del alias IBLocal del BDE. Para obtener los datos, navegar a través de ellos y realizar altas, bajas y modificaciones utilizaremos un componente Table y un control DBNavigator, conectados mediante el correspondiente DataSource. La Figura 1 muestra el formulario con las propiedades que nos interesan. object Form1: TForm1 object DBGrid1: TDBGrid DataSource = DataSource1 object DBNavigator1: TDBNavigator DataSource = DataSource1 object Table1: TTable Active = True DatabaseName = 'IBLocal' TableName = 'COUNTRY' object DataSource1: TDataSource DataSet = Table1 Figura 1 Cliente/Servidor.

3 Al estar accedio a un servidor SQL (en este caso InterBase) y utilizar un componente Table, el BDE se encarga por detrás del telón de generar las sentencias SQL correspondientes para seleccionar (SELECT), insertar (INSERT), borrar (DELETE) y actualizar (UPDATE) los datos. Si observamos detenidamente el comportamiento de la aplicación, veremos que se registra actividad contra la base de datos sólo cuando realizamos algunas de las acciones anteriormente mencionadas, es decir, cuando seleccionamos, insertamos, borramos o modificamos datos. Sin embargo, cuando navegamos a través de ellos no se registra actividad alguna. Esto lo podemos comprobar si observamos el puntero del ratón. Cuando el BDE está accedio al servidor SQL cambia el puntero del ratón a un reloj de arena con la palabra SQL en la parte inferior. La ausencia de actividad contra la base de datos se debe a que el BDE almacena en memoria una copia local de los datos, es decir, soporta caching de datos. En cuanto el conjunto de datos completo ha viajado desde la base de datos a nuestra aplicación cliente el BDE no necesita hacer más peticiones, pues utiliza su copia local. En contrapartida, DBE no soporta caching de datos. Funciona como si utilizáramos un componente Query con la propiedad UniDirectional puesta en True. Al no estar soportado el caching de datos sólo podemos navegar el conjunto de datos obtenido en una sola dirección, es decir, de principio a fin. Entonces, significa esto que ya no podremos visualizar datos en una rejilla y navegar a través de ellos libremente? Si utilizáramos únicamente los componentes basados en DBE, la respuesta sería un rotundo sí. Sin embargo, ya en Delphi 3 se introdujo un componente que por sí solo (en realidad con el auxilio de una DLL) soporta caching de datos. Los conocedores de la tecnología MIDAS sabrán que estoy hablando del componente ClientDataSet. Kylix & MIDAS La gran mayoría de las aplicaciones de bases de datos desarrolladas con Kylix estarán basadas en la tecnología MIDAS. Esto significa que a los componentes que acostumbramos a utilizar para acceder a los datos tremos que agregar otros dos: DataSetProvider y ClientDataSet. El componente DataSetProvider cumple dos funciones principales: obtener datos de componentes DataSet, empaquetarlos y enviarlos a componentes ClientDataSet. resolver las actualizaciones provenientes de componentes ClientDataSet. El componente ClientDataSet es un DataSet especializado que se diferencia de los DataSet tradicionales, como por ejemplo Table y Query, en dos aspectos: obtiene los datos de un componente DataSetProvider y aplica las actualizaciones a través del mismo componente DataSetProvider. Soporta caching de datos, es decir, a medida que obtiene paquetes de datos de un DataSetProvider los almacena localmente en memoria junto con las modificaciones que realiza el usuario.

4 Si quisiéramos desarrollar el ejemplo anterior como lo haríamos en Kylix, deberíamos colocar en el formulario un DataSetProvider con su propiedad DataSet apuntando al Table, y un ClientDataSet con su propiedad Provider apuntando al DataSetProvider anterior. Finalmente, deberíamos modificar la propiedad DataSet del DataSource para que apunte al ClientDataSet. La Figura 2 muestra el formulario con las propiedades que nos interesan. Figura 2 MIDAS object Form1: TForm1 object Table1: TTable DatabaseName = 'IBLocal' TableName = 'COUNTRY' object DataSource1: TDataSource DataSet = ClientDataSet1 object DataSetProvider1: TDataSetProvider DataSet = Table1 object ClientDataSet1: TClientDataSet Active = True ProviderName = 'DataSetProvider1' Al activar el ClientDataSet, éste se encargará de pedirle los datos a su DataSetProvider asociado, que a su vez se encargará de pedirle los datos a su Table asociado, que a su vez se encargará de pedirle los datos a InterBase. Luego, el DataSetProvider se hará cargo de empaquetar los datos y entregárselos al ClientDataSet, y éste los almacenará localmente en memoria. A medida que el usuario utilice la aplicación insertando, borrando y modificando datos, el ClientDataSet se encargará de almacenar esos cambios localmente en memoria. Mediante el método ApplyUpdates el ClientDataSet se encargará de empaquetar los cambios efectuados y enviárselos al DataSetProvider para que éste se encargue de aplicarlos directamente a la base de datos.

5 Si algo anduviera mal durante la aplicación de los cambios, el DataSetProvider se encargaría de empaquetar los datos que no pudieron ser aplicados y enviárselos de vuelta al ClientDataSet para dar al usuario la posibilidad de reconciliarlos, modificándolos nuevamente y volviéndolos a aplicar o descartándolos definitivamente. En un ejemplo simple como éste y con un conjunto de datos pequeño los cambios no parecen ser radicales. La única diferencia estriba en la necesidad de llamar al método ApplyUpdates del ClientDataSet para aplicar todas las modificaciones en la base de datos. Si alguna vez ha utilizado actualizaciones en caché ( cached updates ), pensará que prácticamente no hay cambios con respecto a esta tecnología. Pero como ocurre siempre con este tipo de cosas, la vida real nos plantea situaciones mucho más complejas. Veamos algunas de ellas. Conjuntos de datos grandes Por defecto, el componente ClientDataSet pide a su proveedor todos los registros del conjunto de datos. Si el conjunto de datos es grande, entonces la aplicación se tomará su tiempo hasta que los datos lleguen al ClientDataSet. Este tiempo será aún mayor al que se necesita, por ejemplo, con un componente Table, debido al tiempo adicional que le lleva al DataSetProvider empaquetar los datos. Para disminuir estos tiempos de respuesta tan largos, lo que podemos hacer es indicarle al ClientDataSet que no pida un paquete con todos los registros, sino que pida paquetes con una cantidad reducida de registros. La propiedad PacketsRecords nos permite indicarle al ClientDataSet la cantidad de registros por paquete que debe solicitar. De esta manera, en lugar de tener un tiempo de respuesta largo cuando solicitemos los datos por primera vez tremos tiempos de respuesta más cortos entre peticiones de paquetes. Sin embargo, la cosa no es tan simple. Si le damos al usuario la posibilidad de navegar a través de los datos con una rejilla, entonces corremos el riesgo de que quiera posicionarse en el último registro, para lo cual el ClientDataSet no trá otro remedio que pedir todos los registros. Si el conjunto de datos es grande, seguramente el usuario de nuestra aplicación nos agradecerá sobremanera recordando a todos nuestros familiares, por el tiempo que le damos para que pueda tomarse un café. Otro problema similar puede surgir a la hora de insertar registros. Si el usuario inserta un registro que de acuerdo al índice activo quedaría ubicado cerca del final del conjunto de datos, al hacer ApplyUpdates el ClientDataSet intentaría posicionarse en ese registro, para lo cual no tría otra opción que pedir todos los registros anteriores al recién insertado. Venga otro café para el usuario de nuestra aplicación. Mi madre? Bien, gracias. Concurrencia Como ocurre con el uso de las actualizaciones en caché, las posibilidades de concurrencia se ven ampliamente incrementadas con MIDAS. Un usuario puede pasarse horas insertando, borrando y modificando datos sin enterarse de que otros usuarios

6 pudieron haber borrado o modificado los mismos datos. Concretamente, para un usuario determinado, si entre el momento en que el ClientDataSet obtuvo el conjunto de datos y el momento en que las actualizaciones son aplicadas en la base de datos otro usuario actualizó alguno de los registros que el primer usuario intenta actualizar, estaremos en presencia de un problema de concurrencia. Cuando el DataSetProvider aplica las actualizaciones en la base de datos genera las sentencias SQL para insertar, borrar y modificar registros. La manera en que se generan estas sentencias SQL es controlada por la propiedad UpdateMode del proveedor. El valor de esta propiedad determina qué campos del conjunto de datos serán incluidos en la cláusula WHERE de las sentencias SQL serán generadas. Los valores posibles de esta propiedad son: upwhereall: en este caso, todos los campos del conjunto de datos serán incluidos en la cláusula WHERE. Esto garantiza que si un usuario intenta actualizar un registro que ha sido modificado por otro usuario la actualización no se aplicará. upwherechanged: sólo los campos que el usuario ha modificado, más los que forman la clave primaria, serán incluidos en la cláusula WHERE. En este caso, si un usuario intenta actualizar un registro que ha sido modificado por otro usuario pueden darse dos situaciones: o si algunos de los campos modificados por ambos usuarios coinciden, entonces la actualización no se aplicará. o si ninguno de los campos modificados por ambos usuarios coinciden, entonces la actualización se aplicará. upwherekeyonly: sólo los campos que forman la clave primaria serán incluidos en la cláusula WHERE. En este caso, la actualización siempre se aplicará (salvo que se modifique la clave primaria), pero en la base de datos quedarán las modificaciones aplicadas por el último usuario. Es posible lograr el mismo efecto para cada campo individual del DataSet a través de la propiedad ProviderFlags. Los posibles valores de esta propiedad son los mismos que para UpdateMode, con un valor adicional que no viene al caso explicar en este momento. En el caso de que las modificaciones a uno o más registros no se hayan aplicado, el DataSetProvider empaquetará los registros que no han sido actualizados y se los enviará al ClientDataSet para darle al usuario la posibilidad de resolver el conflicto. El método ApplyUpdates del ClientDataSet recibe un parámetro que indica la cantidad máxima de errores tolerable antes de cancelar el proceso de actualización. Si el valor es 1, no hay límite para la cantidad de errores tolerable. Si el valor es mayor que 1, al llegar al límite de errores especificado el proceso de actualización será cancelado prematuramente. Como ya se ha dicho, el componente ClientDataSet mantiene un registro de los cambios realizados por el usuario. El método ApplyUpdates empaqueta dichos cambios y se los envía al DataSetProvider. ApplyUpdates devuelve la cantidad de errores ocurridos, es decir, la cantidad de registros que no pudieron ser actualizados. Los registros actualizados con éxito son eliminados del registro de cambios, mientras que los registros que no fueron actualizados no lo son. Esto significa que tanto los registros que

7 no fueron actualizados por errores como aquellos que no fueron actualizados por haberse alcanzado el límite de errores tolerable siguen existio en el registro de cambios después de una llamada a ApplyUpdates. Relaciones maestro/detalle En MIDAS las relaciones maestro/detalle son manejadas de una manera especial. La razón principal para ello es que la actualización del registro maestro junto con sus respectivos registros detalle debe ser realizada en el contexto de la misma transacción, de manera que se grabe todo, es decir, maestro y detalles, o que no se grabe nada. Entonces, cómo es la cosa? Bastante simple. En primer lugar, las relaciones maestro/detalle deben ser creadas del lado de los DataSet que acceden a la base de datos y no del lado de los ClientDataSet. Cuando el DataSetProvider detecta que el DataSet asociado es maestro de otro, entonces coloca en un único paquete los registros del maestro y los registros del detalle. Para cada registro del maestro se crea un campo adicional en el que se almacenan todos los registros asociados del detalle. Del lado de los ClientDataSet, si observamos los campos del ClientDataSet maestro veremos que, además de los campos correspondientes al DataSet maestro, hay un campo adicional de tipo TFieldDataSet, que no es ni más ni menos que un DataSet especial con todos los registros del detalle asociados al registro maestro. Cómo accedemos a ellos? Pues a través de la propiedad DataSetField del ClientDataSet. Colocamos un segundo ClientDataSet para los registros del detalle, y en lugar de asociarlo con un DataSetProvider lo asociamos con el FieldDataSet del ClientDataSet maestro mediante la propiedad DataSetField. Para que este mecanismo funcione, debemos crear el FieldDataSet como campo persistente en tiempo de diseño.

8 Figura 3 Maestro/Detalle Object Form1: TForm1 object Table1: TTable DatabaseName = 'IBLocal' TableName = 'COUNTRY' object DataSource1: TDataSource DataSet = ClientDataSet1 object DataSetProvider1: TDataSetProvider DataSet = Table1 object ClientDataSet1: TClientDataSet Active = True ProviderName = 'DataSetProvider1' object object ClientDataSet1Table2: TDataSetField FieldName = 'Table2' object DataSource2: TDataSource DataSet = Table1 object Table2: TTable DatabaseName = 'IBLocal' IndexFieldNames = 'COUNTRY' MasterFields = 'COUNTRY' MasterSource = DataSource2 TableName = 'CUSTOMER' object ClientDataSet2: TClientDataSet Active = True DataSetField = ClientDataSet1Table2 object DataSource3: TDataSource DataSet = ClientDataSet2 De esta manera, los registros del detalle constituyen en su conjunto el valor de un campo del registro maestro. Esto significa que si modificamos un registro del detalle también estaremos modificando el registro maestro. Haga la prueba y verá que si edita un registro del detalle, el ClientDataSet maestro también pasará a modo dsedit. Ahora al llamar al método ApplyUpdates el registro maestro y sus respectivos registros detalle serán actualizados en el contexto de la misma transacción. Si ocurriera algún error durante la actualización, la transacción sería cancelada manteniéndose la integridad de la base de datos.

9 Supongo que habrá notado que la rejilla del ClientDataSet maestro muestra el FieldDataSet. El componente DBGrid ofrece soporte para conjuntos de datos anidados como los que se utilizan en MIDAS para las relaciones maestro/detalle. Si intentamos editar este campo en la rejilla veremos que aparece un botón con tres puntos suspensivos, que al ser pulsado abre un nuevo formulario con una rejilla mostrando los registros del DataSet anidado. Es una lástima que en este formulario no se incluya un DBNavigator. Actualizaciones personalizadas Muy bien. El DataSetProvider ofrece un mecanismo de actualización que nos ahorra mucho trabajo. Pero qué pasa si dicho mecanismo no nos sirve? Fiel a su filosofía, Delphi nos permite personalizar todo hasta el más mínimo detalle. Veamos algunos casos. El DataSetProvider tiene una propiedad llamada ResolveToDataSet que nos permite modificar completamente el mecanismo de actualización. Por defecto el valor de esta propiedad es False, lo que significa que el DataSetProvider se encargará de resolver las actualizaciones por su cuenta. Pero si le asignamos el valor True entonces el DataSetProvider aplicará las actualizaciones al DataSet asociado, como si todas las acciones sobre el ClientDataSet se hicieran sobre este DataSet. Esto nos da la posibilidad de aprovechar los eventos del DataSet ya sea para realizar validaciones o para actualizar otros DataSet. Si los cambios que queremos introducir no son tan radicales, en lugar de asignar True a la propiedad ResolveToDataSet podemos hacer uso de los eventos del DataSetProvider, que por cierto son muchos. Sin embargo, la mayoría de estos eventos están pensados para el modelo de tres capas que es posible desarrollar con MIDAS, sobre todo en lo que tiene que ver con la comunicación entre el DataSetProvider y el ClientDataSet. Tenga en cuenta que en el modelo de tres capas ambos componentes se hallan en aplicaciones distintas que estarán ejecutándose, muy probablemente, en distintos ordenadores. El evento OnUpdateData se dispara antes de que el proceso de actualización comience. El parámetro DataSet es un ClientDataSet con los cambios a aplicar. En este evento podemos recorrer este conjunto de datos cliente para obtener información sobre las actualizaciones que serán aplicadas e incluso modificarlas. El evento BeforeUpdateRecord se dispara antes de que las actualizaciones de cada registro sean aplicadas. Este evento recibe varios parámetros. SourceDS es el DataSet asociado al DataSetProvider. DeltaDS es un ClientDataSet con el registro a ser actualizado. UpdateKind es el tipo de actualización que se realizará y Applied indica si la actualización debe ser aplicada o nosotros nos encargamos de hacerlo en este evento. BeforeUpdateRecord brinda la posibilidad de ejecutar cualquier conjunto de instrucciones antes de que se apliquen las actualizaciones de cada registro.

10 El evento AfterUpdateRecord es similar a BeforeUpdateRecord pero, como su nombre indica, se dispara después de que las actualizaciones a cada registro han sido aplicadas. Los parámetros son los mismos, exceptuando a Applied. Por último, el evento OnUpdateError se dispara para cada registro que no pueda ser actualizado debido a un error. El parámetro DataSet es el ClientDataSet que contiene el registro que no pudo ser actualizado. E es una excepción del tipo TUpdateError que podemos utilizar para obtener información sobre el error ocurrido. UpdateKind es el tipo de actualización que se intentó aplicar para el registro que generó el error. Response nos permite indicar la acción que debe realizar el DataSetProvider al salir del evento. Explicar los detalles de cada uno de estos eventos sobrepasa los límites de este artículo. La intención es simplemente mencionarlos para mostrarle en qué medida es posible personalizar el mecanismo de actualización del DataSetProvider. Conclusiones Para los programadores de Delphi, el Borland Database Engine o BDE forma parte de nuestras vidas. Con sus ventajas y desventajas, con sus soluciones y problemas, ya estamos acostumbrados a él. Sin embargo, como lo único constante es el cambio, con el proyecto Kylix le llegó su turno al BDE. Su sustituto, Database Express o DBE, nos obligará a modificar la manera en que desarrollamos aplicaciones de bases de datos. La razón principal es que DBE no soporta caching de datos. Por este motivo, la tecnología MIDAS será la piedra angular de las aplicaciones de bases de datos en Kylix. Es posible que Ud. nunca antes haya utilizado los componentes de la página MIDAS de la Paleta de Componentes, ya sea porque nunca los necesitó, porque no tuvo tiempo o no sintió la suficiente curiosidad, o simplemente porque no tiene la versión Enterprise de Delphi. Lo cierto es que si tiene planes de migrar sus aplicaciones a Kylix, entonces es hora de que comience a experimentar con la tecnología MIDAS. Como con toda nueva tecnología (nueva para los que no la conocen, ya que MIDAS fue introducida en Delphi 3), trá que enfrentarse con nuevos problemas que requerirán nuevas soluciones. A lo largo de este artículo hemos visto cómo utilizar los componentes DataSetProvider y ClientDataSet para desarrollar aplicaciones de bases de datos como lo haríamos con Kylix. También hemos presentado algunos de los problemas con los que nos deberemos enfrentar, y cómo solucionarlos o minimizar sus efectos. Sin embargo, todavía queda mucha tinta en el tintero y poco a poco la iremos utilizando para conocer más a fondo la tecnología MIDAS. Consultas o comentarios Cualquier consulta o comentario sobre este artículo será bien recibida por nuestro equipo, contacte con nosotros en soporte@danysoft.com.