Reorg - Poder marcar tablas como de Alta Cardinalidad (Enrique Almeida)
Poder marcar tablas de alta cardinalidad y diferenciarla de otro color en el IAR.
Poder marcar tablas como que se replican (Marcos Crispino)
Nos pasa que en algunos lugares tenemos dos bases de datos (un cliente con dos instalaciones), y algunas de las tablas se replican.
El problema es que no es lo mismo reorganizar una tabla que se replica que reorganizar una que no, hay que hacer cosas distintas.
Siguiendo en la línea de lo que pidió Enrique (poder marcar tablas como alta cardinalidad), sería bueno también poder identificar fácilmente este caso.
Evitar reorganizacion por nombres de indices en ambientes con SQL (Enrique Almeida)
Tener la opcion de que GeneXus maneje en forma automatica los nombres de los indices y que no haga reorganizaciones si los mismos cambian, para ambientes que manejen SQL.
Otra cosa buena seria tener una opcion en la consolidacion "Do not overwrite / System Index Name".
Reorg - Analisis de Impacto - Contar registros en base de datos (Enrique Almeida).
Poder hacer que la reorganizacion, ejecute en modalidad, ANALISIS DE IMPACTO, de tal forma que muestre todo lo que va a hacer, contando los registros de las tablas que estan involucradas en dicha reorganizacion, de tal forma de poder estimar cuanto puede demorar la misma.
Mostrar en la pantalla de la reorganizacion, sobre que base va a correrse dicha reorganizacion. Es imporntate cuando una reorg debe correrse sobre muchas bases de datos diferentes.
armin 01/09/09 02:16 PMImplementado en GX X: ver Reorganization features detail
Opcion para mostrar que va a hacer la reorganizacion (Enrique Almeida)
Seria bueno contar con una opcion que muestre que es lo que la reorganizacion va a realizar y en que orden, listando que tablas esta por modificar, reorganizar, etc. pero que NO REALICE LAS OPERACIONES.
De esta forma podriamos ver si la reorganizacion va a realizar el cambio que nosotros deseamos.
Implementado en GX X: ver Reorganization features detail.
Reorg - Opcionalmente dejar objetos como pendientes de generar (Paco Marjalizo).
Cuando se realizan cambios de atributos las transacciones quedan como pendientes de especificar, sin embargo los objetos que usan dicha tabla o atributo no quedan como pendientes. Eso obliga a hacer un build all de la kb para asegurar que todos los objetos que trabajan con ellos han sido generados de nuevo. Cuando la KB es muy grande eso puede llevar muchas horas cuando si solo se generasen los objetos afectados se reduciria mucho el tiempo. Eso se podria conseguir con esta sugerencia. Esto quizas podria ser aplicado tambien a otros casos como los subtipos, dominios, structuras (SDT), etc. Quizas podria ser configurable el comportamiento.
armin 01/09/09 02:16 PMImplementado en GX X: ver Build process
Reor Batch (Alejandro Rinaldi)
Para que sirve una pantalla que lo unico que hay que hacer es apretar un boton y tener una persona frente a la pantalla para apretar el boton? Mejor seria si se pudiera hacer la reor en batch y el log que se genere a un archivo o salida estandar. Asi se podria agendar un bat que ejecute la reor a la madrugada.
WA: reor.exe -NOGUI !! solo habia que adivinarlo! :D
Reorganizaciones como Script SQL (Enrique Almeida) Se muestra en la ROCHA
En vez de generar un programa ejecutable, generar la reorganizacion en dos etapas.
1) Script sql para las modificaciones de la estructura de tablas, borrado de tablas, DDL en general
2) Ejecutable del generador que haga la copia y transformacion de los mismos.
Esta solicitud, es para permitir a los DBA modificar y controlar cuales seran los cambios que se van a realizar en la base de datos. Tambien facilita el poder ejecutar la reorganizacion por partes, por ejemplo en 2 noches, en vez de hacerlo todo en la misma corrida.
armin 01/09/09 02:16 PMImplementado en GX X: ver Reorganization features detail.
Impactos parciales (Paco Marjalizo)
Poder elegir que cambios de BDD de un modelo a otro queremos impactar. Ahora obligatoriamente se esta forzando a que todos los cambios pasen de un modelo a otro dentro de la kb. En ocasiones algun cambio no lo podemos pasar y eso obliga a retroceder ese cambio en diseño para poder impactar y posteriormente volver a aplicarlo. Eso seria interesante.
armin 01/09/09 02:16 PMEsto en GeneXus X Evolution 1 se puede resolver cambiando metodología de trabajo con Knowledge Base Versions y Change Defender
ReorgReflexiones