Ya me he quedado un poco más tranquilo con el asunto del caché de consultas SQL de que hablé en la anterior entrada. Después de otras cuentas vueltas, llego a la conclusión de que no sería bien desactivar el caché en la propia clase "GbDb" de Gesbit (como había propuesto y hecho antes) sino en la clase "Admin", y, en general, en el caso de borrar varios objetos de la base de datos al mismo tiempo. ¿Por qué no aplicarlo en la clase "GbDb"? Porque si borro una categoría de entradas no se da el problema del caché, únicamente se da si borro más de una categoría.
¿Y dónde sé que voy a borrar más de una categoría? En la clase "Admin", concretamente, en el método dedicado a ese menester: ahí sé si voy a borrar una o más categorías. Sin embargo, todavía cabría pensar que claro, a toro pasado... como sé que ahí se produce el problema, pues ahí pongo el parche, pero, ¿y si se da en otras circunstancias? Es lo que comentaba en la entrada anterior. Y, sin embargo, he decidido de momento desactivar el caché de consultas SQL ahí, precisamente, en los métodos de la clase "Admin" dedicados a llevar a cabo tareas sobre varios objetos a la vez.
Hacerlo así, quiere decir que, si alguna vez termina de ponerse en marcha el API de Gesbit, y este permite borrar varias categorías de entradas, por ejemplo, digo, en este caso, tocaría hacer exactamente lo mismo que en la clase "Admin": deshabilitar el caché de consultas SQL. Pero sigo viendo esta solución como la mejor, que se me ocurra ahora mismo. Quitar del medio el caché de consultas no es una buena idea: en primer lugar porque ya se hace uso del mismo (lo he comprobado) en algunas páginas de las bitácoras, y, en segundo lugar, porque todavía puede usarse más.
Deshabilitarlo para todos los "scripts" de administración tampoco parece una buena idea, teniendo en cuenta que los posibles problemas se presentan en situaciones muy concretas. Así que, de momento, creo que me voy a quedar tranquilo tal como dejo las cosas. Y a procurar en adelante, cuando se trabaje con la base de datos, y, sobre todo, cuando se borren registros de la misma, digo, procurar tener en cuenta el caché de consultas SQL. Joroba, que no estamos hablando de que un determinado tema sea más o menos bonito: estamos hablando de la integridad de la base de datos, ni más ni menos.
