Administrador de Persistencia
El objetivo de los objetos de persistencia (Datos-Tabla y Datos-Relación) es brindar una API generica de trabajo sobre estructuras de tipo tabla y sus relaciones. Con el fin de abstraerse del medio físico final en donde estas estructuras se almacenan se separan las funcionalidades de carga y sincronización en una clase aparte llamada Administrador de Persistencia.
Base de datos relacional
La única implementación de la abstracción de una estructura de datos tipo tabla y sus relaciones es una tabla en un base de datos relacional y sus asociaciones con otras tablas. El nombre que recibe este administrador de persistencia es:
Las responsabilidades de una AP de una relación son:
- Determinar el orden y la forma de carga a partir del medio de persistencia.
- Determinar el orden y la forma de sincronización con el medio de persistencia.
El AP de base de datos para asegurar que las tablas hijos se cargan en base a los datos presentes en los padres, se utiliza el query de la tabla en el subselect. A medida que se aleja de las tablas raices se incluyen los select de la tabla padre.
Concurrencia
La concurrencia se da cuando dos o más usuarios intentan editar un registro al mismo tiempo. Si no se toma alguna medida, el registro queda con valor del ultimo que guarda, lo preocupante es que ninguno de los involucrados toma conocimiento del problema y todos piensan que son sus valores los finales.
La alternativa implementada en los componentes de persistencia es el llamado locking optimista, donde al momento de guardar se controla que en el interín de la edición nadie haya modificado el registro. Esto asegura que cuando la aplicación indica que un dato fue guardado, todas las ediciones concurrentes sean marcadas como inválidas, quedando el valor del primero que guarda como valor final.
Este control está habilitado por defecto desde toba 1.4. En caso de no
querer el control es posible desactivarlo en los metadatos general del
datos_relación o via API.
Tratamiento del Error
Cuando se detecta el error de consistencia, por defecto toba lanza una excepción con un error genérico y deja un mensaje en el log (visible al usuario si está en modo debug) con el detalle de la inconsistencia. El proyecto puede definir una política distinta de mostrar el mensaje de error e incluso recuperarse de alguna forma del problema. Para ello el proyecto puede redefinir la ventana toba_ap_tabla_db::evt__perdida_sincronizacion donde se recibe el id de la fila y la SQL origen del conflicto.