En realidad esta entrada iba a ser para anunciar un nuevo "sistema" de opciones para Gesbit, hasta cierto punto, mejorado en algunos aspectos, pero, aunque llevo trabajando desde ayer en ello, todavía no estoy seguro de su implementación definitiva, sigo haciendo pruebas y más pruebas, además de plantearme sus posibles consecuencias, con el fin de que se me escapen las menos macas posibles.

Así que escribiré esto también para mí, para ver si soy capaz de seguir mis razonamientos y estos me siguen convenciendo. No obstante, si alguien quiere comentar algo al respecto se agradecerá. Se trata de lo siguiente. Gesbit cuenta en su base de datos con una tabla para guardar sus propias opciones, tabla que también pueden usar los plugins para guardar sus propias opciones también. Eso está bien.

Ya he hablado por aquí del plugin VozMe de xEsk para Gesbit, que propoció varios cambios en Gesbit. Algunos están directamente relacionados con las opciones, y es que VozMe es el primer plugin para Gesbit que hace uso de esta posibilidad: guardar sus propias opciones usando la base de datos de Gesbit. Pues bien, por otro lado, pedí a xEsk que implementara sus opciones de tal manera que sólo utilizara un registro en la tabla "options" de la base de datos.

Esto es perfectamente posible, y un registro no tiene que limitarse a guardar una opción, sino que puede guardar varias, como es precisamente el caso de VozMe. Existen dos tipos de opciones, básicamente, en Gesbit, las que se "cargan" desde un principio, y las que no es preciso cargar desde un principio. Las primeras, son requeridas de la base de datos cuando se inicia Gesbit, y las segundas se cargarán sólo cuando sean necesarias, pero no desde el principio.

En realidad estamos hablando de una consulta SQL, justamente, la que trae las opciones de la base de datos. Ahora bien, tengamos en cuenta que esta consulta se hace siempre, al iniciarse el "sistema" de Gesbit. Esto quiere decir que, siguiendo con el plugin VozMe, al principio Gesbit pide a la base de datos las opciones de este, recordemos que guardadas en un solo registro de la tabla opciones.

Además de las opciones de VozMe, guardadas en un registro, Gesbit trae de la base de datos sus propias opciones, y aquí viene ya el meollo de la cuestión. Gesbit cuenta actualmente con 17 opciones. Lo que quiere decir que Gesbit hace una sola consulta SQL a la base de datos, que trae 17 filas, cada una de ellas correspondiente a una determinada opción. 18 filas, si se usa el plugin VozMe para Gesbit.

Ahora bien, si le propuse a xEsk que guardara sus opciones en un solo registro (porque si no habría que traer 20 filas, nótese), ¿por qué no intentar también que las opciones de Gesbit se guardaran también en un solo registro? De este modo sólo habría que traer de la base de datos 1 fila, si no hay plugins instalados en Gesbit que hagan uso de este tipo de opciones. 1 fila no son 17, pero, aún hay más.

Tengo entendido que una de las formas de darse cuenta de que una consulta SQL necesita optimizarse, es que esta requiera demasiadas filas. En realidad en Gesbit no se nota nada "lento", teniendo en cuenta, además, que algunos gestores de bitácoras tienen más de 70 opciones (de entrada) y por tanto tienen que pedir 70 filas de opciones en cada inicio. Gesbit, sin los cambios que ahora hago, pide 17 filas.

No se nota nada en el rendimiento, Gesbit va bien, estamos hablando quizás de milisegundos, y pocos. Mas, sin embargo, Gesbit podría tener más opciones. Es decir, no bajaremos de las 17 filas, antes al contrario, es posible que se sumen más opciones, que serán filas que luego habrá que traer de la base de datos. No sé si llegaremos a 70, que me parecen muchas, pero, el caso es que esto no parece "escalar" bien.

Supongamos que una bitácora usa 20 plugins. Y que los 20 usan opciones (es raro, piénsese que VozMe es el único plugin de los seis que existen actualmente que necesita hacer uso de opciones: el resto de plugins no las necesita y no las usa, por tanto), imaginemos que cada plugin usa 5 opciones, lo que no parece un número desproporcionado. 20 x 5 = 100 opciones, 100 + 17 + N = 117 + N.

¿Se ve ahora claro dónde está el problema? Entonces habría que traer de la base de datos más de 100 filas, para lo que se utiliza una sola consulta SQL, es cierto, pero, una consulta SQL que trae demasiados registros, en mi opinión, sobre todo porque podemos hablar de 50 plugins, en lugar de 20. Sé que no será normal tener instalados 50 plugins, pero, en principio, nada debería impedir tenerlos instalados.

Bien. La idea, por tanto, los cambios en que estoy trabajando, implican que Gesbit guardará sus opciones en un solo registro de la base de datos. Seguirá guardando 17 opciones, por el momento, pero, todas ellas en un solo registro, que ocupa menos de 3 KB, por cierto. Así, traer las opciones de Gesbit de la base de datos costará una sola consulta SQL, que traerá una sola fija de datos. A todas luces, esto es una mejora.

Es una mejora, porque además, "escala" mejor. Si mañana tengo que añadir a Gesbit opciones nuevas, en realidad se seguirán guardando en el mismo registro, no estaremos aumentando el número de filas de la tabla "options" de la base de datos de Gesbit. Conseguir esto ha hecho necesarios algunos cambios, aunque, después de varios intentos fallidos, al final no ha resultado tan complicado como pudo parecer al principio.

Además, he añadido lo necesario en la clase "GbPlugin" (de la que heredan todos los plugins para Gesbit) de manera que estos pueden ahora guardar sus opciones, siguiendo este "estilo", sin apenas esfuerzo. Los plugins pueden guardar en la base de datos un "Array" de opciones, simplemente, pares de claves y valores, y Gesbit se encargará de "serializar" el Array, así como de "deserializarlo" cuando el plugin solicite sus opciones.

Más mejoras se introducen aquí siguiendo con los plugins, y es que hasta ahora los plugins son responsables de borrar sus opciones, cuando los plugins son desactivados o desinstalados. De este modo se pretende evitar que la tabla opciones contenga registros que realmente no son necesarios sin la presencia de este o aquel plugin. Con los cambios hechos, el plugin ya no tiene que preocuparse de esto tampoco.

De hecho Gesbit se encarga de determinar el nombre del registro en la tabla de opciones que le corresponde a un plugin, y el propio Gesbit se encarga de borrar este registro de la base de datos cuando un plugin se "desactiva". Ahora bien, paremos aquí un momento, si todo funciona como digo, si además ya está hecho, ¿qué impide que actualice Gesbit y anuncie estos interesantes cambios en lugar de estar escribiendo esto?

En primer lugar, estoy haciendo pruebas, pruebas, pruebas y más pruebas. Quiero asegurarme de que Gesbit guarda y recupera sus opciones sin problemas, que no se pierden datos, etc. Pero, fundamentalmente, lo que me ha parado ha sido darme cuenta de que este nuevo "sistema" para guardar opciones tiene otro lado, no tan positivo, y que puede resultar contraproducente. ¿De qué se trata? De lo que digo a continuación.

Si decimos que un registro guardará muchas opciones, hay que pensar cuántas opciones y qué cantidad de opciones. Porque, si bien es cierto que parece mejor una consulta SQL que traiga una sola fila, que otra consulta que traiga 17, no es menos cierto que si esa fila contiene una gran cantidad de datos... la balanza se puede ir del otro lado. Ya no es tan seguro que este sistema escale como se esperaba en principio.

Añadamos a esto el hecho de que, como he dicho arriba, no se nota un mal rendimiento en Gesbit, trayendo esas 17 filas desde un principio. Recordemos que hay gestores de contenidos que traen 70, y tampoco se nota una pérdida de rendimiento verdaderamente significativo. Las 17 opciones de Gesbit ocupan, en un solo registro, 3 KB, apróximadamente. ¿Pero qué ocurriría si estas ocuparan más espacio?

Supongamos un plugin que quiera guardar traducciones de entradas a otros idiomas. Este plugin puede guardar cientos de entradas. Para eso podría usar 100 filas en la tabla de opciones. Estas opciones no tendrían que ser "autocargables". Ahora bien, si este plugin guarda las 100 "entradas traducidas" en un solo registro de la tabla opciones... ¿no parece ya más costoso esto último que lo primero?

En el segundo caso el plugin traería una fila de la tabla opciones base de datos, esto es completamente cierto, pero, traería una fila que "pesaría" considerablemente, ¡¡sobre todo porque puede que no fueran necesarias las 100 entradas traducidas!! Esta idea fue lo que anoche me decidió a parar máquinas, y a darle vueltas a todo este asunto. Si un plugin necesita una de sus "entradas traducidas"... que tenga que pedir todas las que tenga ya está diciendo que algo no va bien.

Ahora bien (y quiero ir terminando), ¿entonces qué? ¿Qué puede hacerse? ¿Cómo se sale de este "atolladero"? En primer lugar entrecomillo atolladero, porque, en Gesbit, no hay problemas de rendimiento que puedan apreciarse. Al menos hasta donde yo llego. Así que, si todo lo que hay que hacer es deshechar el trabajo que he realizado entre ayer y hoy, no sólo estoy dispuesto a hacerlo, sino que lo haré con mucho gusto. ¿Pero hay una solución?

Tal vez no hay una solución, porque, vayamos por donde vayamos, hasta donde yo puedo entender, se llega a un lugar muy parecido. Pero igual sí que hay varias soluciones, consistentes, precisamente, en que se puedan emplear ambos modelos, ambos "sistemas" para guardar opciones. Así, un plugin podría guardar sus opciones en un solo registro, en varios de ellos, o en ninguno, si no lo necesitara. Incluso Gesbit podría elegir también.

Ahora bien, el dilema sigue presente. Gesbit puede guardar sus opciones en un solo registro, porque parece que funciona, y que lo seguirá haciendo con este tipo de opciones, incluso cuando se añadieran más en el futuro. Acabo de probar a triplicar el número de opciones y todo parece funcionar bien, y el registro ocupa algo menos de 6 KB. Recordemos que estamos hablando de traer una fila, o traer 51 en este último caso.

De cualquier forma hay que traer los 6 KB, pero, me parece que no es igual traerlos en una fila que en 51. Y el plugin VozMe podría seguir haciendo uso de solo un registro, para guardar sus actuales 3 opciones. Además, el plugin VozMe, por ejemplo, podría utilizar este nuevo sistema, beneficiándose de los métodos que he preparado en la clase "GbPlugin" a tal efecto. Todavía podría guardar en un futuro más opciones sin problema alguno.

Cada vez estoy más convencido de que debe ser así. Porque, por otro lado, todavía se ofrece la posibilidad a los plugins que lo necesitaran, de utilizar otros registros de la tabla para opciones de la base de datos. ¡En realidad un plugin puede crear su propia tabla y hacer uso de ella! Pero, para buena parte de los plugins, que necesiten opciones, podrá servirles el primer método, es decir, guardar sus opciones usando un solo registro, sencillamente.

En fin. Creo que me he enrollado demasiado. Dudo mucho que alguien haya leído hasta aquí, tal vez con razón. Pero al principio dije que escribía estas líneas también para mí, y creo que, al cabo, mi discurso se mantiene bastante sólido. Esto quiere decir que, si después de varias pruebas más, todo va bien, me plantearé actualizar Gesbit introduciendo estos cambios, entre otros que también he llevado a cabo últimamente.

Si después de leer esto, se te ocurre comentar algo al respecto, te lo agradeceré. Es probable que tú veas el asunto de otro modo, o sepas más de SQL que yo (lo cual no sería extraordinario, te lo aseguro), en fin. En todo caso si los cambios se llevan a cabo será para mejora de Gesbit y de sus plugins. Y si no se lleva a cabo, pues bueno, qué le vamos a hacer, unas veces las cosas salen bien y otras veces no salen bien, salen mal. Ya veremos.