Por curiosidad (y Parte III)

Nos habiamos quedado en la propiedad Delta…

Tanto la propiedad Data como Delta se definen como OleVariants, y se organizan internamente como un array de bytes, y es esta característica la que va a dotar de flexibilidad a las dos estructuras, que soportaran por un lado los datos, el contenido real, en el caso de la propiedad Data, y un registro de actualizaciones que representa a la propiedad Delta. Dicho registro, logicamente es de solo lectura, dado que es la unica forma de garantizar que es tan solo manipulable por el propio dataset. Tambien es por esa razón, ya que no nos es permitido modificarlo, es por la que existen metodos que nos permiten limpiar esa cache de datos que contiene los registros de cambios.

Pero lo mejor es que lo veamos con unos cambios. Lo primero que he hecho es modificar el navegador de articulos para que nos deje insertar, habiltando todas las opciones. Como solo vamos a poner nuestra atención en la tabla de articulos nos podemos olvidar de los detalles y del mecanismo para transmitir el valor a las claves ajenas desde la inserción del articulo. Sobre este punto, yo os volvería a remitir a los cursos de Ian Marteens, accesibles desde su web a un precio razonable. Esto con independencia de que podamos mas adelante comentar este punto. El framework que desarrolla Martens en cada capitulo de esos cursos aborda una buena cantidad de detalles necesarios para trabajar con el esquema DataSnap, tanto a dos como a mas capas.

Os propongo unos cambios en los datos de la tabla articulos. Los hago y vemos los resultados:

La rejilla inferior os muestra el contenido del registro de actualizaciones. La estructura es identica a nivel de campos, a la que contiene la propiedad Data, como ya hemos comentado. Pero en el delta, por cada registro existente en el data, pueden existir máximo un par de registros vinculados a éste. Segun el caso, ya que para las inserciones o los borrados tan solo necesitamos un registro y mantener en algun «sitio» algo que nos diga si es un borrado o una inserción (en ese punto interviene UpdateStatus con los valores [usModified, usInserted, usDeleted]). En el caso de las modificiones, el primero registro representa el contenido original y el segundo los nuevos valores que toma.

Si yo modificara repetidamente el registro correspondiente al articulo A0005, los cambios sobrescribirian repetidamente el segundo integrante del par, lo cual no es ni bueno ni malo, pero si es esclarecedor, si en algun momento piensas, al revertir los cambios, un comportamiento similar al de cualquier deshacer (ej Word en office) de las aplicaciones mas habituales.

Y retomando ya el motivo que originó estas tres entradas, ahora que ya estamos en contexto de poder razonarlo, parece dificil encontrar la forma de generar un metodo que de forma limpia y sencilla provoque el refresco de uno de los detalles cualquiera sin tener que liarse a crear nuevos conjuntos de datos auxiliares que invoquen en un segundo plano el contenido a importar. Quiero decir que no parece sencillo añadir un nuevo metodo o una nueva función que nos permita decirle:
– ¡Oye, majo!, que no quiero los detalles de la tabla composicion. Haga Vd el favor de mostrarme los valores correctos…

Y el problema en mi opinión (y como siempre digo es mi opinión y no tiene porque coincidir ni ser acertada) es el diseño en bloque de ambas cachés. Si tuviera que buscar una analogia quizás lo compararia a esas muñecas rusas que nunca sabes por el exterior cuantas van a contener salvo que las vayas abriendo de una en una hasta llegar hasta la que tu deseas.

Nunca llueve a gusto de todos, decía mi padre. Así que me queda la pregunta si hubiera podido existir una alternativa que hubiera contemplado que estas cachés se hubieran repartido de forma equitativa a cada uno de los componentes ClientDataSet, dejando que cada palo hubiera aguantado su vela.

Ni idea… 😦