Esto es buenísimo en la mayoría de los casos: En vez de yo tener que pensar y hacer cambios manualmente en unos 2,20,200 o más objetos, GeneXus + Patterns lo hace automáticamente.
Pero el arma tiene dos filos. No siempre se desea que las instancias u objetos "emparentados" se cambien. A veces definitivamente no se desea y a veces temporalmente; por ejemplo cuando preciso hacer un cambio puntual en un objeto para enviar ese objeto a producción y quiero posponer los posibles cambios a los demás objetos.
En particular, dependiendo también de la implementación del pattern y de la complejidad y tamaño de la KB, los cálculos y operaciones para actualizar automáticamente instancias y objetos pueden ser muy costosas. Estamos hablando de varios segundos o minutos de overhead al salvar un objeto en algunos casos.
Es para esto que existe la propiedad Dynamic Pattern Update con valores YES|NO a nivel de KB Version.
En forma predeterminada está en YES; si la configura en NO, agilizará el desarrollo en determinadas situaciones.
Esta funcionalidad existe desde GeneXus X Evolution 1, la menciono ahora porque me he chocado en estos últimos días con varios reportes del estilo "demora mucho el salvado de una trn en la xev1" y averiguando detalles siempre surgió que la demora no era en el salvado de esa trn sino en los subsecuentes cálculos.
Más sobre esta funcionalidad y relacionadas:
4 comentarios:
Me encanta la funcionalidad!!!
Sugerencia!!!
Quiero las dos!!
Yo incorporaría en una cola todas las tareas pendientes, y procesaría de fondo cuando la KB se encuentra ociosa.
En ocasiones el usuario está leyendo un fuente o haciendo otra cosa en windows, podría aprovecharse esos momentos para hacer algunas cosas de fondo para acelerar ese tipo de tareas.
El proceso si se dispara de forma asíncrona al salvado no afecta los tiempos del mismo, y como va adelantando tiempo antes del build, cuando el build ocurra se hace de forma forzada los pendientes como lo hace con la nueva funcionalidad
Si se vuelve a modificar un elemento que afecta algo que está en la cola y aún no fue procesado no debería de reasignarse, cuando llegue el momento la notificación de la cola le dirá que acción hacer haciéndolo sobre la última acción realizada. (si en 10 minutos anduve tocando lo mismo, cuando quede idle solamente encontrará una acción a realizar y no decenas de ellas repetidas).
Con esto pienso que se podría mejorar "la percepción" del usuario, el salvado es rápido, y el build pasaría a hacer menos tareas.
Con la misma idea se podría tener un adelanto de tareas que hoy en una de esas se hacen en el build adelantando trabajo sin que el usuario se percate de esto mismo, dejando todo pronto para el momento de generación o compilación (me imagino algo relacionado a estructuras internas o datos para la generación,no se exactamente que corre detrás del build como para darle la sugerencia exacta de si se puede o no optimizar).
Gracias David, van algunas excusas: El qué hacen esos cálculos depende muchísimo del pattern (nuestro o de terceros) y además mientras se salvan objetos otros no se puede hacer save,build,import y todas esas cosas.
Además solo serviría para el caso que lo quieras posponer; pero son muchos los casos donde ni siquiera quieres que otras instancias se recalculen.
Adelantar trabajo para el build no necesariamente se puede porque el build no es solo compilación; es copymodel, es reorg, etc.; también es una de esas que mientras sucede no puedo hacer save,import, etc.
Estamos hablando de normalizar también...
O sea, creeme que no lo queres :-)
Ok, entiendo!!!
No es todo solo generación de código o actualización de código. Me imagino que si se conociera que tipo de impacto realiza una actualización de Pattern podrían tomar la decisión de qué momentos efectuarlo.
De todas formas, lo que mencionas de que a veces definitivamente no se desea o se quiere delegar en el tiempo es algo cierto.
De todas formas pienso que se puede adelantar trabajo, no estoy diciendo que se impacte directamente un objeto, sino que se almacene el cambio a efectuarse y que se delegue el cambio para que se haga directamente sobre el momento del build.
Si por ejemplo me cuesta detectar la lista de todos los objetos a impactar, o el impacto genera código que impacta objetos o tablas, estaría bueno que todo quedara "pronto" en la ventana X de tiempo y se aplicara directamente en el momento del build.
No se si se entiende.. pero estoy diciendo algo como "un cache" de cambios a aplicar.
Si por ejemplo el impacto de análisis de una Reorg, lo podría precalcular luego de haber realizado el cambio, pero no aplicarlo realmente en ese momento (no estoy impactando nada realmente), sino dejarlo ya "precalculado" para directamente el momento del build, de la misma forma cuales objetos actualizar y ese tipo de cosas.
Hoy me imagino que la tarea de "update/copymodel" analiza cuales son las diferencias para efectuar la actualización.. cuando en realidad mientras se efectúan esos cambios se podría ir construyendo la lista y preparando exactamente el cambio a realizar para después realizarlo efectivamente en el momento que se necesite hacerlo.
Me imagino que por ejemplo la Reorg podría tener camino ya adelantado en el análisis de impacto, y que por ejemplo los generadores ya tener la información que necesitan para su lógica prolog de antemano para solo dedicarse a generar.
La idea es no construir "el entorno necesario" en el momento de la acción, sino tener a alguien que de fondo va adelantando trabajo (sin realmente efectuar impactos).
Si algo del entorno cambia, ese "demonio" que labura de fondo se dará cuenta y reconstruirá lo que necesita.
Si se maneja con una cola de tareas a realizar, se podrá conocer de antemano cuanto falta y forzarlo a realizar dado el momento del Build/Reorg/CopyModel o lo que sea.
Dejo de opinar, los amigos de desarrollo en una de esas ya están usando algo similar a esto de fondo :) o ya tienen algo de esto para la EVO II.
Hola, Armin, yo la demora que estoy teniendo es en el hacerle build with only sobre un objeto que tiene atributos con varias formulas.
He realizado la prueba de comentar las formulas y demora en vez de 40 minutos , 5 minutos. esto tiene que ver o se solucionaria con lo comentas?
Saludos, cordiales
Publicar un comentario