| matiash | |
Hola Sebastián,
En principio es correcto que al salvar usando el editor de instancia ésta
no se aplique, ya que lo que provoca que se aplique en el otro caso es el
flag "apply this pattern on save" en la transacción. Sin embargo, este
apply pendiente *sí* debería realizarse automáticamente en el momento del
build (F8). Es un error que no esté ocurriendo.
Te pediría por favor que te comuniques con soporte y nos pases lo necesario
para reproducir el problema (i.e. tu pattern más lo necesario para llegar a
este estado).
Saludos,
- Matías
On Fri, Apr 29, 2016 at 12:19 PM Sebastián Cardello <
scardello@acpsistemas.com.ar> wrote:
> Gente:
>
> Tengo un problema con la eliminación automática de objetos en el Pattern
> cuando ya no es necesario generar ciertos objetos, que lleva a una
> diferencia de funcionamiento cuando se edita desde el editor de instancia o
> desde el editor desde el parent object (pestaña Pattern). Estoy
> desarrollando un pattern que tiene como parent object una transacción y que
> además genera otra transacción. La transacción se genera o no en función de
> que exista un nodo del pattern. A continuación 2 imágenes para ilustrar
> esta operación. La primera con la rama "Recorder process" (con recuadro
> rojo) genera la transacción y un par de procs. La segunda, misma instancia
> pero que no tiene el nodo, no debería generar nada:
>
>
> Ahora para explicar el caso empiezo ilustrando el funcionamiento correcto
> desde el editor de pattern en la transacción (paso a paso):
> 1) Aplico el pattern por defecto (que incluye el nodo), guardo y me genera
> la transacción correctamente. Luego F8, se realiza el análisis de impacto y
> la reo. Todo perfecto.
> 2) Siguiendo en el editor de pattern desde la transacción elimino el nodo
> "Recorder process" (imagen 2). Guardo y todo se resuelve correctamente. Me
> da el siguiente mensaje (notar los delete en negrilla):
> ========== Pattern generation (DataSyncTrnx2) started ==========
> Saving Attribute 'DSTrnx2Id'... (forced) succeeded.
> Saving Attribute 'DSTrnx2DT'... (forced) succeeded.
> Saving Attribute 'DSTrnx2Sts'... (forced) succeeded.
> Saving Attribute 'DSTrnx2Ope'... (forced) succeeded.
> Saving Structured Data Type 'DSTrnx2Record'... (forced) succeeded.
> Saving Procedure 'DSTrnx2Acquire'... (forced) succeeded.
> Saving Procedure 'DSTrnx2WipeSrc'... (forced) succeeded.
> Saving Procedure 'DSTrnx2Write'... (forced) succeeded.
> Saving Procedure 'DSTrnx2WriteRecord'... (forced) succeeded.
> Saving Procedure 'DSTrnx2ConflictSolver'... (forced) succeeded.
> Saving Procedure 'DSTrnx2Generic'... (forced) succeeded.
> Saving Transaction 'Trnx2'... succeeded.
> * Deleting Procedure 'DSTrnx2Recorder', Procedure 'DSTrnx2Init',
> Transaction 'DSTrnx2'...succeeded.*
> Pattern generation (DataSyncTrnx2) Success
>
> Notar que toda la operación fue correcta, ya que se eliminó la transacción
> y los procedimientos que dependían del nodo. Luego F8 y me detecta el
> impacto y la reo.
>
> Ahora el inconveniente. Si realizo el paso 2 *pero usando el editor de
> instancia directamente *luego de guardar no se reaplica el pattern y por
> ende no se detecta el cambio de la eliminación nodo. Luego F8, y el mensaje
> es el siguiente:
> ========== Pattern generation (DataSync) started ==========
> Refreshing instance 'DataSyncTrnx2'
> Pattern generation (DataSync) Success
>
> Como consecuencia: los objetos que genera el nodo (los indicados en el
> Delete en negrilla) no están, porque no se generaron, pero tampoco se
> eliminaron ya que de haberse eliminados se debería haber provocado el
> análisis de impacto y por ende la reorganización. Este comportamiento
> también se repite cuando se utiliza GxServer y se hace un commit de una
> instancia que ya no tiene la rama "Recorder Process". Notar la gravedad del
> asunto: *los objetos desaparecen silenciosamente (entre ellos la Trn) y
> se pierde una reo.*
>
> Ahora mis cavilaciones. ¿Esto es un bug de Gx? Si no lo fuera, ¿cómo se
> resuelve este caso? ¿Existe alguna forma de que el
> "PatternInstanceValidator" detecte si se está ejecutando o no en modo
> "forzado" y que fuerce la aplicación del pattern en la próxima generación?
> ¿Existe otra forma de codificar la no generación de un objeto sin que
> adolezca de este inconvenientes? ¿Debe el desarrollador del pattern
> detectar y eliminar estos objetos por código?
>
> Gracias a los que llegar a leer hasta este punto. Cualquier
> idea/comentario es bienvenido.
>
> Saludos!
>
> --
> Ing. Sebastián C Cardello
> ACP Ing. en Sistemas
> Tel (+54 261) 4296686
> Av. España 943 PB. Of. 1
> Mendoza, Argentina
>
>
|
|
|
|