Hoy, casualmente, he descubierto un par de errores importantes en Gesbit, de los que menos me gustan, porque tienen que ver con la integridad de la base de datos. El segundo error lo consideraría grave, puesto que Gesbit puede dejar "sin listar" un enlace existente en la base de datos, pero, cuya categoría se desconozca. Y es que ambos errores (uno me llevó al otro) tienen que ver con el borrado de las categorías de entradas y enlaces, aunque, en el caso de las entradas, estas siguen mostrándose, aun sin que estén asociadas a categoría alguna.
Pero, el problema es que deben estar asociadas al menos a una categoría: la categoría principal o predeterminada, y así está "pensado" en Gesbit, es decir, cuando se borra una categoría de entradas, se comprueba si dichas entradas se quedan "sin categoría", y, de ser así, Gesbit se encarga de asignar a estas entradas la categoría predeterminada. ¿Dónde estaba el problema? Al borrar varias categorías de una vez, cosa que es posible, empero, entraban en juego el caché de consultas SQL, y, como alguna otra vez en el pasado, no tenía que hacerlo.
El asunto se las trae, porque, primero me ha costado llegar a la conclusión de que lo que fallaba era el caché de consultas SQL, es decir, se estaba "cachando" alguna consulta que no debía, y, por decirlo así, no podía completarse el proceso del borrado de las categorías correctamente. Vale. De acuerdo. Lo que falla es el caché. Ahora, ¿dónde establezco que no se use el caché de consultas SQL cuando se pretenda borrar una categoría de entradas? ¿En el "script" del panel de administración correspondiente? ¿Pero y si se quiere borrar una entrada desde fuera del "script", como pudiera ser, en un futuro, usando el API de Gesbit?
Total, que no queda nada claro dónde especificar que no se use el caché de consultas SQL en este caso. ¿Será mejor hacerlo en la propia clase "GbDb"? ¿Pero dónde? No puede hacerse alegremente, porque, por ejemplo, podemos identificar qué consulta exactamente no debe guardarse, pero, esta consulta puede usarse también en otras tareas, no sólo para borrar una determinada categoría de entrada, así que, ¿dónde se sitúa el "Set Caché Queries Off"? De moment, y, para salir del paso, lo he situado en el propio método que inicia el proceso para borrar categorías, tanto de entradas como de enlaces, en la clase "GbDb".
Pero, no me quedo satisfecho. En primer lugar, porque, ¿quién dice que no existen otros errores similares pero que todavía no se han encontrado, simplemente? Hay que tener en cuenta que yo he descubierto el error con las entradas de categorías por casualidad, y que he deducido que pasaría lo mismo con las categorías de enlaces, como así he podido comprobar. Entonces, ¿quién dice que no hay más errores de este mismo tipo pero que todavía no han aparecido? Me parece tan grave esto, que, una de las posibles soluciones que me he planteado ha sido la de prescindir del caché de consultas SQL.
Sobre todo, cuando he querido ver cuántas consultas SQL se estaban "cacheando" en mi bitácora personal, donde además uso varios plugins, y he comprobado que no se estaba "cacheando" ninguna consulta, es decir, que daría igual usar el caché o no usarlo. Pero, claro está, ¿hace esto inútil al caché de consultas SQL? Nada de eso. ¿¡Para qué lo implementamos sino!? El caché de consultas SQL es útil, desde luego, o puede serlo, en la composición de temas y para el trabajo de plugins, así pues, prescindir del mismo no parece una buena idea. Y, sin embargo, el mismo también está causando problemas: es un arma de doble filo, como suele decirse.
Así que no sé qué hacer. Claro, ahora mismo los errores que he referido en esta entrada están arreglados, o quedan arreglados, deshabilitando el caché de consultas SQL en sendos métodos de la clase "GbDb", pero, de verdad que no me queda nada claro tener que hacerlo así. Como no quiero alargarme demasiado lo dejaré aquí, recomendando actualizar a los pocos usuarios que estén utilizando Gesbit, y, si a ti que lees esto se te ocurre alguna cosa sobre lo dicho, te agradecería que la comentaras por aquí, a ver si entre todos podemos aclarar algo más este asunto. ;-)
Actualización: Ver esta otra entrada.
