Conciliar una versión es un proceso lento o requiere mucho tiempo para completarse

Descripción

Al conciliar, ocasionalmente el proceso de conciliación es lento o requiere mucho tiempo para completarse.

Al conciliar, es importante comprender el proceso que realiza la conciliación internamente y por qué el flujo de trabajo de una organización puede tener un impacto significativo en el rendimiento de una conciliación.

Nota: Este artículo corresponde a las versiones 8.x y 9.x de ArcGIS. Es posible que versiones posteriores de ArcGIS incluyan funcionalidades distintas, así como nombres y ubicaciones distintos para menús, comandos y herramientas de geoprocesamiento.

Causa

Durante una conciliación, todas las ediciones realizadas en la versión de origen, la versión que se edita y concilia con una versión de destino y la versión de destino que es la versión principal o la versión DEFAULT, se copian en la versión de destino y se detectan y se presentan conflictos mediante el cuadro de diálogo de resolución de conflictos.

El tiempo necesario para conciliar depende del número de ediciones. Para entender mejor por qué depende del número de ediciones, es necesario comprender la jerarquía de estado de la geodatabase versionada.

Cada edición que se produce en una geodatabase versionada se identifica de forma única con un state_id. El conjunto de estados de una geodatabase versionada se denomina jerarquía de estado, y cada estado participa en un linaje de estados que se origina del estado 0, el estado base. Cada linaje de la jerarquía de estado representa sesiones de edición diferentes o versiones diferentes.

La única relación de la jerarquía de estado con una versión es el estado al que la versión hace referencia. Sin embargo, la jerarquía de versiones influye en las versiones que se pueden conciliar entre sí. Una conciliación sólo se puede realizar en una versión en un predecesor directo, como la versión principal o la versión que precede a la principal, etc.

Sin embargo, no muestra la historia completa de cómo se relacionan las versiones con los estados de la geodatabase. En el siguiente ejemplo, observe que la versión Editor2 es una versión secundaria creada a partir de la versión Trans_mnt, pero no se visualizan ni la estructura de la jerarquía de estado ni cómo se corresponden las versiones con estados específicos.

En esta jerarquía, Editor1 se puede conciliar con Trans_mnt o DEFAULT.

Al conciliar una versión con una versión de destino, todas las ediciones del linaje de la versión de origen, que no son comunes al linaje de la versión de destino, se copian a un nuevo estado en el linaje de la versión de destino. En el siguiente ejemplo, Trans_mnt y Editor1 tienen un estado de predecesor común, estado 40.

Aquí se pueden ver los linajes de las versiones:

• Trans_mnt: 0, 40, 41, 52
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

El estado más elevado es común en ambos linajes de la versión. Las ediciones sin conflictos de los estados 78, 92 y 97 se copian en el linaje de la versión de destino. Los estados únicos del linaje de Editor1 (78, 92 y 97) se copian en un nuevo estado del linaje de Trans_mnt. El nuevo estado de la geodatabase es el estado 99.

El diagrama anterior no indica cuántas ediciones hay en los estados 78, 92 y 97. Si solo hay una edición para una clase de entidad por estado, entonces el estado de conciliación, 99, solo contiene las tres ediciones realizadas en los estados 78, 92 y 97, lo que da como resultado 3 nuevas filas en las tablas de adiciones y borrados de clases de entidad.

Sin embargo, si se actualizan las 50.000 entidades para el estado 92, entonces, durante el proceso de conciliación, todas las 50.000 ediciones se deben copiar al estado 99 e insertarse en las tablas de adiciones y borrados de clases de entidad. Por lo tanto, habría 50.000 ediciones para el estado 92 y otras 50.000 ediciones para el estado 99.

Además, la geodatabase debe identificar los cambios entre los dos linajes de la versión para identificar conflictos durante una conciliación. Los conflictos se categorizan en los siguientes grupos:

• Actualizaciones/Actualizar conflictos.
• Actualizar/Eliminar conflictos.
• Eliminar/Actualizar conflictos.

Las ediciones que no estén en conflicto ni relacionadas con los objetos que están en conflicto se copian en el estado de conciliación de la versión de destino. Las ediciones que están en conflicto se muestran en el cuadro de diálogo de resolución de conflictos.

El número de ediciones del linaje de la versión de origen afecta al rendimiento de la conciliación.

Los flujos de trabajo deben tener en cuenta adecuadamente estas situaciones.

Solución o solución alternativa

Al trabajar en una geodatabase versionada, el flujo de trabajo para crear y conciliar versiones es muy importante. Con varias versiones secundarias de una versión principal, el orden de conciliación y publicación de las versiones secundarias en la versión principal también es importante.

Si la versión de destino no se ha modificado desde que se creó y editó la versión de origen, el proceso de conciliación no tiene que copiar ninguna modificación, ya que cada versión comparte el mismo linaje. En estos casos, si el usuario publica después de conciliar, la versión de origen y de destino se actualizan para hacer referencia al mismo estado de la base de datos.

En el siguiente ejemplo, la versión Trans_mnt, o la versión principal, no se ha modificado desde que se crearon las versiones Editor1 y Editor2. La versión Trans_mnt hace referencia al estado 40, que es el estado predecesor común de las versiones Editor1 y Editor2.

El siguiente es un ejemplo de la jerarquía de estado antes de la conciliación. Observe que los linajes de las versiones son:

• Trans_mnt: 0, 40
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

Observe que la versión Trans_mnt hace referencia al estado 40. El linaje de la versión Editor1 es: 0, 40, 78, 92, 97.

Cuando se concilia Editor1 con la versión Trans_mnt, no hay necesidad de copiar todas las ediciones del linaje actual de Editor1 a un nuevo estado para la versión Trans_mnt.

El siguiente es un ejemplo de la jerarquía de estado después de la conciliación. La versión Editor1 se concilia con la versión Trans_mnt. En este caso, la versión Trans_mnt hace referencia a un estado que se encuentra a lo largo del mismo linaje que Editor1, de modo que no es necesario copiar las ediciones en un estado de conciliación.

Si se realizaron 50.000 actualizaciones en el estado 92, las ediciones no se copian al estado 99 porque ya existen en el linaje de la versión. En este caso, la conciliación es muy rápida, ya que no hay conflictos que descubrir y no hay ediciones que copiar en el estado de una versión de destino.

Cuando se hace clic en el comando Publicar, las versiones Editor1 y Trans_mnt hacen referencia al mismo estado: estado 99.

A medida que continúa el flujo de trabajo, la versión Editor2 se concilia y publica en Trans_mnt.

Para esta conciliación, se ha modificado la versión Trans_mnt o principal y hace referencia a un nuevo estado, por ejemplo, estado 99, que se encuentra en un linaje diferente al de la versión Editor2. Para conciliar las ediciones de la versión Editor2, todas las ediciones del estado 56 se copian en un nuevo estado en el linaje Trans_mnt.

Cuando hay varias versiones secundarias creadas a partir de la misma versión principal, las operaciones de conciliación invariablemente dan lugar a que las ediciones de un linaje se copian en otro linaje. Para minimizar la cantidad de datos que se copian, concilie y publique la versión con el mayor número de ediciones primero, lo que reduce el número de registros que se copian y almacenan en las tablas de adiciones y borrados de las clases de entidad.

Comprender las consideraciones del flujo de trabajo para la conciliación es especialmente importante cuando se realiza un gran número de ediciones en una versión secundaria o si se edita en masa. Para una versión que se utiliza para la edición en masa, intente siempre conciliar esta versión con su destino antes de modificar la versión de destino.