KBDoctor : Para que sirve?

En el GeneXus Marketplace esta la extensión KBDoctor, que desarrollamos con Diego y Marcos hace unos cuantos años.  Se basa en una herramienta que teniamos para GeneXus 9.0, que permitia depurar KBs.

Hace unos días, me preguntaron para que servia y si valía la pena instalarla.

La idea de esta extensión, es poder corregir algunos problemas comunes que se presentan en KB GeneXus.

A la pregunta si vale la pena instalarla, mi respuesta es que si vale le pena, pues permite diagnosticar algunos problemas y solucionar otros. También permite borrar aquellos objetos que no están siendo usados, que enlentecen el desarrollo y entorpecen el mantenimiento.

Voy a contar cuales son los reportes que pueden sacarse.

Reporte de Atributos

Todos los atributos deben estar basados en dominios.
El reporte "Attributes without domain", permite listar todos aquellos atributos que no estan basados en dominios y que a su vez no son subtipos de otros atributos.
Facilita detectar cuales son los atributos que hay que modificar.

Attributes with no description 
Lista y permite modificar, aquellos atributos que tienen la descripciones que deja por defecto GeneXus.
Permite cambiar el titulo contextual, de las columnas, etc. Es importante ajustar estos literales asociados a atributos, porque ayudan muchisimo en el diseño de pantallas sobre todo si uno basa su desarrollo en patterns.

Attributes Description without unique index. 
El atributo marcado como descripcion en cada tabla, es conveniente que no se repita. Por ejemplo, si tenemos una tabla de paises, no es bueno que dos tengan exactamente el mismo nombre, pues despues se dificulta su identificacaion. Por ejemplo, si hacemos un Dynamic Combo y mostramos las descripciones, se hace imposible saber de que valor estamos hablando viendo unicamente la descripcion. Si se define un indice unico por dicho atributo, este problema se soluciona.

Atributes without table. 
Si la base de conocimiento tiene varios años, es posible que se borren tablas, pero queden atributos referenciados (por ejemplo  variables en objetos, que dependan de artibutos). Estos atributos no pueden ser borrados porque están referenciados aun. Este reporte permite identificarlos.
En la nueva versión (que aun no fue liberada), ya se quitan las referencias en variables y se intenta borrar dichos atributos.

Attributes Char that should be VarChar. 
Estos son atributos char de largo mayor que 50. La mayoria de estos atributos, es conveniente definirlos como Varchar, pora que ocupen menos lugar en la base de datos, optimizando asi el almacenamiento y la performance de la base de datos.

Attributes VarChar that should be Char. 
Los atributos de largo menor a 25 y tengan largo variable, son listados. Estos no se consideran un error, sino que hay que revisarlos.

Attributes Varchar y Key. 
En algunas bases de datos, la comparación de campos VarChar y Char, es problematica, pues los blancos al final, hacen que se tengan diferencias. Por ejemplo, en Oracle, algunos joins entre varchar y char no traen los tuplas correspondientes. Por eso, es recomendable no tener campos clave con campos Varchar. Este reporte lo que hace es listar todos los atributos que son varchar y son clave en alguna tabla, para que se pueda revisar y corregir.

Reportes de Tablas


Tables with no description. 
Este reporte lista todas tablas que no tienen descripción, o que tiene un descripción por defecto.
Permite cambiar la descripción. Es importante poner descripciones bien descriptivas de las tablas, porque las mismas se muestran en los mensajes de integridad referencial de las transacciones y si la tabla tiene un descripción que al usuario no le dice nada, puede provocar problemas de usabilidad.

Subtype groups whit no description. 
Al igual que la tabla, en algunos mensajes se usan las descripciones de los subtipos. Es conveniente que los mismos tengan descripciones que expresen el contenido de dicho subtipos.

Table Width. 
Este es uno de los últimos reportes incorporados al KBDoctor. Muestra el ancho de las tablas (sumando el largo de cada uno de los atributos que la componen). Permite identificar tablas que tengan muchas campos en la clave, que tengan claves demasiado grandes lo cual enlentece la inserción de registros y también muestra la suma de los campos de ancho fijo y los de ancho variable (como varchar, longvarchar).

Reporte de indices.


Indexes with not referenced attributes. 
Uno de los problemas mas comunes de performance, es tener demasiados indices definidos. Algunas veces, es dificil identificar cuales son los indices que no se usan.
La mayoría de las base de datos, brindan reportes de indices no utilizados, pero desde GeneXus es difícil saber cuales son. Este reporte lo que permite es identificar aquellos indices que tienen atributos que no son referenciados por nadie, por lo que el indice (o parte de el) , no esta siendo utilizado por la aplicación generada.

Reportes de Objetos. 


Object not referenced. 
Son aquellos objetos que no son main y que no son referenciados por nadie. Estos objetos pueden borrarse y la aplicación va a seguir funcionando sin inconvenientes. Es conveniente hacer un backup de los mismos y luego borrarlos.

Not reachables objects. 
Este es uno de los reportes mas utiles del KBDoctor. Permite identificar aquellos objetos que no son alcanzables desde ninguno de los objetos main de la aplicación. Ademas de generar un listado, marca a dichos objetos como no generables y los pone en una categoría (KBdoctor.Unreachable) para que sea fácil trabajar con ellos. Se identifican que tablas se dejaron de usar en la aplicación, que atributos podrían borrarse, etc.

With parm() without in:/out:/inout:
Este reporte tiene los objetos que tienen reglas parm() pero no están declarados si sus parámetros son de entrada o de salida. Hace mucho tiempo, todos los parámetros de los objetos en Genexus eran de entrada salida, por lo que es común tener muchos objetos en las KB que no tienen especificados como deben usarse los parámetros.
Es importantisimo establecer el uso de parametros en los objetos, porque queda muchísimo mas claro, la semántica de los objetos, al saber como se van a tratar los parámetros que recibe o devuelve.
Ademas, es una fuente común de errores, el que se modifique un parámetros que se cree que es solo de entrada pero es modificado en el objeto llamado. Recomiendo fuertemente que todos los objetos que tengan regla parm() especifiquen en todos sus parametros si son in:/out: o inout:.

Wtih variables not based in attributes/domain. 
Es conveniente basar las variables en atributos o en dominios. De esta forma, cuando modifique algo en mi atributo, se va a modificar también en las variables basadas en el.
Este reporte muestra cuales son los objetos que tienen variables que no se basan en dominios o atributos y permite corregirlos.

With parm() y Commit on Exit = YES. 
Cuando un objeto, tiene regla parm() puede inferirse que va a ser llamado por otros. Si tiene la regla Commit on Exit = YES, puede hacer que se quieber la integridad transaccional, cortando la transaccion en la base de datos. Es conveniente tener identificado todos los objetos que hacen commit en la base de datos, para que no se nos escapen errores.

Object with variables not used. 
Este reporte muestra cuales son los objetos que tienen variables definidas, pero no son referenciadas.
Desde hace un tiempo utilizo mas el Variables Cleaner desarrollado por DVelop, pues es mas práctico que este reporte, pues ya borra todas las variables que no están siendo usadas.

Estoy trabajando en una versión del KBDoctor que permita hacer mas cambios en la KB, por ejemplo la opción "Clean my KB as much as possible", va a dejar todos los objetos que se necesitan para generar la aplicación, pero va a borrar todo lo accesorio. Como modifica la  KB, tengo que probarlo bastante para no hacer demasiados destrozos.

También estoy trabajando en algunos reportes que identifican objetos "complejos" (grandes, con muchas dependencias, etc) y otro que identifica objetos "similares" (candidatos a refactoring).

Estén atentos a las próximas versiones.

Comentarios

  1. Muy bueno, lo voy a usar en breve para desacoplar un nueva KB en la EV2 de otra KB monstruosa migrada.

    Wishlist para la próxima versión:

    - Que en el listado de resultados (de objetos not referenced, etc.) puedas seleccionar/deseleccionar todos o varios; filtrarlos x tipo, si es main o no, etc. Y luego
    hacer remove sobre los seleccionados.

    - Que opcionalmente puedas considerar a un objeto como "referenciado" si aparece en algún literal del llamador. Reconozco que es rebuscado, pero es por aquello cuando te encontrás con N llamadas x javascript, para no tener que ir con cada obj. al Language a ver si lo nombran.

    saludos!!
    Mariano.

    ResponderEliminar
    Respuestas
    1. Mariano:
      Gracias por el comentario.

      - Para el primer pedido, deberiamos crear una ToolWindows en el proyecto. En algun momento lo tuvimos, pero nos trancamos en algunos reportes y lo dejamos para mas adelante (y nunca lo hicimos). Lo anoto para la proxima y veo si puedo hacerlo.

      - No creo que lo haga con literales, sino que he evaluado agregar una categoria donde el usuario pueda poner todos aquellos objetos que se tomen como referenciado aunque no lo este. Esto sirve cuando se tienen llamadas dinamicas a objetos y tambien te puede servir en tu caso, aunque te daria un poco de trabajo armar la lista.

      Eliminar
  2. Hola.
    Qué buena se ve la herramienta! Felicitaciones!

    Una consulta, disculpa que la haga en este tema.
    Trabajo con Gx9 con generador Java y BD PostreSQL.
    ¿Hay alguna forma de cambiar, en un Report, la ubicación de una leyenda en tiempo de ejecución? Por ejemplo, para imprimir cheques con diferentes formatos, donde para un banco el importe va en la posición 300,200 pixeles y para otro iría en 310,180 pixeles, por ejemplo.

    Saludos!

    ResponderEliminar
  3. En la 9.0, las posibilidades que tenes son limitadas.

    Podes hacer un reporte, con lineas de texto que ocupen todo el largo y en tu programa, concatenar para posicionarlo donde tu quieras.

    En la X, hay reportes que puede definir el usuario donde se imprime.

    ResponderEliminar
  4. Muchas gracias por la pronta respuesta.
    Es una buena idea, sí señor. Mientras no tenga la X, lo solucionaré de ese modo.
    Gracias!

    ResponderEliminar
  5. buenas la kbDoctor para genexus 9 no lo tendran por alli, ya que lo busque en el marketplace pero para esa version ya no se encuentra, si alguno lo tuviera y me pasara el link se los agradeceria

    ResponderEliminar
  6. Hola Unknown, el KBDoctor esta liberado unicamente para GX X Ev1 y Ev2 (por el momento).

    El KBDoctor para GX 9.0 nunca lo hicimos publico, porque le falta como para que sea un producto usable. De publicarlo me llegarian consultas sobre como se usa y no tengo tiempo ahora para responderlas.

    ResponderEliminar
  7. ok gracias como estaba viendo otro post sino estoy mal suyo de como migrar a genexus GX, que habia que correr ese para poder depuarar antes de migrar, pero deplano entendi mal ese otro post http://ealmeida.blogspot.com/2008/07/migrando-de-genexus-90-genexus-x.html, que hablaba de correrlo pero deplano entonces ha de ser depues de haber migrado.

    ResponderEliminar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

El Sordo

StackOverflow Documentation

Codigo simple