Hay dos categorias dentro de la competencia:
- desarrollo de una base de conocimiento GeneXus usando la versión 9.0
- desarrollo de alguna extensión para GeneXus Rocha.
En Concepto decidimos participar en la segunda categoría, desarrollo de extensiones para GeneXus Rocha.
Después de evaluar varias alternativas, nos decidimos por dos proyectos: KBDoctor y .Net data provider for GX Rocha.
KBDoctor
El KBDoctor es una herramienta que tiene ya algún tiempo, desarrollada utilizando GXPublic para accedera a bases de conocimiento con versiones 9.0 y anteriores.
Básicamente consiste en un conjunto de consultas que permiten analizar y corregir algunos de los problemas comunes en las bases de conocimiento.
Por nombrar algunas de estas consultas:
- objetos no alcanzables
- atributos sin descripción
- atributos sin domino
- índices no usados (parcialmente)
- etc.
La idea es desarrollar una extensión para GeneXus Rocha que integre estas consultas al ambiente de desarrollo, y que puedan interactuar con los objetos de la KB.
A modo de ejemplo, la consulta de atributos sin dominio muestra una lista de dominios que coinciden con el tipo de datos del atributo, y con un click permite asignar el dominio seleccionado al atributo.
En este proyecto estamos participando Diego Crutas, Enrique Almeida y Marcos Crispino (o sea, yo).
.Net data provider for GeneXus Rocha
Una de las cosas que tenía útiles GXPublic, era poder hacer consultas select en la base de conocimiento. Con Ernesto Trelles habíamos desarrollado el KBQuery, que permite realizar consultas de forma muy sencilla en la KB.
Como Rocha no tiene esta posibilidad, decidimos implementarla...
Pero cuidado, a no confundir... no estamos desarrollando una versión de GXPublic para GX Rocha. GXPublic era un OleDB provider, nosotros estamos desarrollando un .Net data provider.
Básicamente eso significa que el código que ya existe desarrollado con GXPublic NO va a funcionar. Lo que sí esperamos, es que una vez completado el proyecto, se puedan usar las sentencias SQL que ya existían.
En este proyecto estamos participando Alexander Wolff y también yo...
4 comentarios:
Lo del .NET data provider parece interesante, pero vale la pena? Quiza con LinQ en C# 3.0 tengan la misma funcionalidad sin nada de trabajo. No se cuan bien juega LinQ sobre la KB pero deberia funcionar bien.
Otra idea seria hacer un Powershell provider (http://msdn2.microsoft.com/en-us/library/ms714636.aspx).
Eso dejaria escribir apps que accedan la KB sin usar C#, y creo que seria muy util para tareas adminstrativas, similar a lo del msbuild pero mucho mas flexible.p
Justo hace unos meses trabajé en un proyecto en el que desarrollamos una capa de datos 100 % LINQ.
Y está bárbaro, como potente es igual que SQL y la sintaxis..no tiene comparación con nada de lo que he visto(que dicho sea de paso es la misma sintaxis para acceder a tablas, colecciones y XML). Y si creo que no hay limitaciones para usarlo con GXRocha, de hecho una vez que el programador sabe como obtener por ejemplo la colección de atributos de la KB..el conjunto de operaciones que puede hacer sobre la colección..seguro son mucho mas potentes que las que se van a poder hacer en esta y muchas versiones futuras del provider pero..uno de los objetivos principales del provider es que el programador no tenga que conocer la BL de GXRocha para acceder a la KB, o sea no tendría ni porque saber que existe el SDK..sino que la idea es que le alcance con saber programar ADO.NET y conocer las tablas relacionales análogas a las de GXPublic.
Y la diferencia es que LINQ recién entraría en acción una vez que se obtuvo de la KB la colección sobre la que se quiere operar...
Lo que me pareció realmente interesante y no conocía es lo del PowerShell Provider pero ya hasta estuve viendo las interfases que hay que implementar para hacer un PowerShell Provider for GX :)
A mi la imágen que se me vino a la mente cuando leì la idea del ado.net provider for KB, es a Claudia Murialdo haciendo el acceso del generador .net y al "Mastro" agregando el DBMS "KB" en la lista de dbmses soportados en genexus, y a nosotros todos haciendo for eachs sobre los data views a KBs importados via DBRET...
Se que el camino es largo, pero me encantó!!
Estaría bueno tener un generador que pueda consultar mediante un for each el contenido de una base de conocimiento. Era lo que quería hacer Enrique.
Pero estoy de acuerdo que queda mucho trabajo, y sobre todo, mucho trabajo de ustedes :)
Publicar un comentario