Al versionar con ArcSDE, ¿se pueden cancelar o rechazar las ediciones publicadas?

Question

Estoy utilizando ArcGIS 9.3.1 e intento trabajar con una geodatabase SDE (con una clase de característica de polígono) que ya ha sido registrada como versionada. Soy nuevo en el tema de las versiones y todavía estoy tratando de entender algunas de sus funciones básicas. Hasta ahora, no he podido descubrir si es posible "cancelar" o "rechazar" ciertas ediciones una vez que han sido publicadas en una versión padre.

Por ejemplo, digamos que tenemos tres versiones: la original SDE.DEFAULT que se creó cuando se registró como versionada, una versión hija de la predeterminada llamada SDE.QA (para el control de calidad), y una versión hija de la QA llamada SDE.Edit1 (donde las ediciones tienen lugar primero). Si se editan ciertas características de SDE.Edit1 (por ejemplo, para simplificar, digamos que se ha añadido un polígono y se ha eliminado otro) y luego SDE.Edit1 se concilia con SDE.QA y posteriormente se contabiliza en SDE.QA, ¿habría alguna forma de deshacer este cambio posteriormente? Siguiendo con esta pregunta, ¿sería posible rechazar sólo algunos cambios? Por ejemplo, ¿aceptar la adición del primer poli, pero rechazar la eliminación del segundo poli?

Por lo que sé, una vez que se han publicado las ediciones en la versión principal, todos estos cambios son ahora una parte "permanente" (a falta de una palabra mejor) de la versión principal. Soy consciente del hecho de que estos cambios se registran en dos tablas, las tablas "ADD" y "DELETE" (a menudo denominadas tablas "delta"), y no cambian realmente la FC original. He considerado la posibilidad de modificar manualmente estas tablas delta, pero he encontrado suficientes personas que advierten de ello para saber que probablemente no sea la solución adecuada.

Tal vez sea mi forma de entender el control de versiones la que necesita algo de trabajo, pero no he podido encontrar una forma de rechazar un cambio o deshacerlo una vez que se ha publicado. Esto me parece extraño, ya que esto significaría que no hay manera de deshacer una publicación que contenga un error. Tampoco puedo encontrar una manera de rastrear el linaje de estas versiones (es decir, qué versión es hija de qué padre). Ya que estoy hablando de este tema, si alguien conoce alguna referencia particularmente útil de ArcSDE (enlaces, artículos, libros, etc.) que pueda ayudarme a entender ArcSDE (y quizás a responder algunas de estas preguntas), ¡se lo agradecería mucho!

---

Aunque las respuestas hasta ahora han sido útiles (gracias por los enlaces), sigo sin encontrar una respuesta al núcleo de mi pregunta. Una vez más, tal vez se trate de mi propia incomprensión de la situación. Esto es lo que quiero saber:

¿Se puede invertir (por invertir me refiero a deshacer ) un puesto una vez que se ha hecho de una versión hija a una versión padre? En este escenario, el padre puede ser, pero no tiene que ser, la versión SDE.DEFAULT. Aún mejor, me gustaría saber si se puede revertir una parte de un mensaje (por ejemplo, una sola edición de un polígono), después de que se haya publicado? También me gustaría saber si esto se puede hacer sin necesidad de que se haya detectado algún conflicto.

El hecho de que no pueda encontrar una respuesta clara a esta pregunta (es decir, "sí" o "no") documentada en ningún sitio me hace pensar que me estoy perdiendo algo importante sobre el versionado en el ArcSDE. También preferiría evitar la manipulación manual de las tablas A y D.

Answer 1

Uf. La respuesta es realmente complicada y requiere muchos conocimientos de ArcSDE, así que intentaré ser lo más breve posible.

Nota: Voy a referirme a algunos diagramas del un impresionante libro blanco sobre versiones que puede encontrar en el sitio de ESRI . Si está tratando con el versionado, le recomiendo encarecidamente que lo lea detenidamente.

Entonces, hay que entender cuál es la relación entre un estado (es decir, un nodo del árbol de estado) y un versión con nombre (es decir, una etiqueta que señala un estado).

Una base de datos típica puede tener el aspecto del siguiente diagrama de estado:

Aquí tiene cuatro versiones en la base de datos (Versión A, Versión B, Versión C y DEFAULT). Pero quizás me estoy adelantando un poco. Comencemos con lo que es un estado es.

Se puede pensar en un estado como una "transacción", una unidad lógica que contiene varias ediciones a una o muchos - mesas. Puede incluir dos inserta a la "FeatureClass A", una borrar de la "Clase de características B" y un modificar (efectivamente una supresión + una inserción) a la "Clase de características X". Todo agrupado en uno.

Veamos un pequeño y sencillo diagrama de estado de ArcSDE que comienza en el estado id 0:

Si empiezas en el estado 0 y realizas ediciones en una o varias tablas en una operación de edición, crearás un estado 1 hijo y harás que ese sea el estado activo actual id . Otro grupo de ediciones posteriores creará el estado hijo 2. Si quieres deshacer, no necesitas modificar el id de estado de ninguna manera - todo lo que necesitas hacer es cambiar el id de estado activo actual a 1, o 0 (dependiendo de lo lejos que quieras ir). Rehacer es lo opuesto - simplemente mueve el id de estado activo actual hacia adelante - tan lejos como quieras ir.

Así es como funciona deshacer/rehacer en el versionado de ArcSDE.

Bien, sigamos. Digamos que quieres hacer una edición permanente (es decir, quieres guardar). ¿Qué tienes que hacer? Bueno, guardar es simplemente tomar una etiqueta de versión y moverla hacia adelante a un estado particular. Algo así como estampar un sello y decir "este es el aspecto que debe tener la versión A". Así que si vuelves a mirar el primer diagrama, verás que tiene cuatro versiones con nombre .

• La versión B apunta a la identificación del estado 1

• La versión A apunta a la identificación del estado 3

• La versión C apunta a la identificación del estado 5

• La versión "SDE.DEFAULT" apunta al estado id 4

  Tenga en cuenta que este diagrama, a pesar de la creencia popular, no le dice cualquier cosa sobre el lógico relación padre-hijo que tienen. La relación lógica padre-hijo para el primer diagrama podría tener el siguiente aspecto:

Esta es la relación padre-hijo que se ve en ArcMap/ArcCatalog. Su propósito es restringir con qué versiones se puede conciliar. Llegados a este punto, podrías preguntarte (con razón), ¿por qué demonios necesito esto? La respuesta está en flujos de trabajo de versiones . Resulta que la gente ha estado usando el versionado desde hace bastante tiempo y hay algunas formas preferidas de cómo estructurarlas, pero ese es un tema para otro día ya que quiero responder a tu pregunta hoy :)

Siguiendo...

Bien, ¿qué más hacen estas versiones con nombre? Bueno, afectan a cómo este proceso llamado comprimir se comporta.

Comprimir consiste en coger estados intermedios que pueden no ser necesarios, y eliminar los innecesarios, así como combinarlos. Puede activar la operación de compresión de ArcSDE a través de ArcCatalog, configurar un servicio que lo haga de vez en cuando, y algunas operaciones de edición de ArcMap activarán mini operaciones de compresión (es decir, sólo para las pequeñas ramas que se están utilizando).

El diagrama de la izquierda muestra un árbol de estados antes de ser comprimido, y el de la derecha lo muestra justo después de ser comprimido:

Un concepto importante que hay que entender (al que me referiré una vez que por fin pueda responder a tu pregunta) es que cada estado es un candidato potencial a ser comprimido - excepto los estados que tienen etiquetas (es decir, versiones con nombre) apuntando a ellos.

Puedes ver que antes de la compresión hay algunos estados extra - innecesarios. De hecho, toda la rama [3,4,5] fue eliminada. Si hubiera habido una versión con nombre en 5, el resultado final habría sido muy diferente.

Las operaciones de compresión sirven para ahorrar espacio en su base de datos eliminando los registros que ya no necesita.

Bien, sigamos.

El último concepto que debes entender, es conciliando - lo que supone la fusión de dos ramas en una.

Volvamos a nuestro primer diagrama. Digamos que queremos conciliar la versión A con SDE.DEFAULT.

Recapitulemos: cuatro versiones con nombre que apuntan a varios identificadores de estado. Así que lo primero que tenemos que hacer, es crear un estado hijo bajo la versión de destino, así que creamos un estado hijo bajo el id de estado 4, en nuestro ejemplo, lo llamo id de estado 20.

El siguiente paso es calcular las diferencias entre ambas versiones (los detalles son demasiado largos para este post, pero te puedo decir que se hacen con cursores de diferencia ) y luego aplicar esas diferencias a ese nuevo estado id 20 (línea azul).

Digamos que decide hacer más ediciones o que encontró conflictos y está eligiendo filas de una versión, o de la otra. No importa. Esas son sólo nuevas ediciones, y se hacen dentro de una operación de edición, como estados hijos debajo de la rama que has fusionado. En este ejemplo, he hecho dos grupos más consecutivos de ediciones después de la reconciliación.

Precioso.

Así que ahora digan que están listos " Correo electrónico: " la versión. ¿Qué significa eso? Eso es solo agarrar las etiquetas y apuntarlas al mismo id de estado. Aquí, voy a poner la versión A en SDE.DEFAULT. Esto es lo que parece:

¡TADAAA! Así que ahora la versión A y SDE.DEFAULT apuntan al mismo id de estado, y por lo tanto tienen el mismo aspecto.

Bien, entonces ahora Por fin puedo responder a su pregunta.

¿Se puede deshacer un mensaje? La documentación de ArcGIS le dirá no - no te metas con él. No lo hagas, porque estarás jugando con esta lógica, y si no sabes lo que estás haciendo, puedes corromper tus datos.

Pero en realidad, todo lo que se necesita es hacer una actualización de uno de los Tablas de versiones de ArcSDE - la tabla VERSIONS, y modificar la entrada de la etiqueta (también llamada versión). En nuestro ejemplo, señale el id de estado 21, y acaba de deshacer toda la operación de edición. Póngalo en 3, y acaba de deshacer toda la reconciliación. Póngalo en 5, y ahora está en un lugar completamente diferente. Que haya o no conflictos es irrelevante.

Por supuesto, esto supone que no se ha producido una compresión. Consideremos el caso en el que la compresión está ocurriendo justo al mismo tiempo que usted está actualizando la tabla SDE. Recuerde, si usted - o alguien más - ejecuta una compresión después de que usted publicó esto es lo que el árbol se ve:

¿Se puede deshacer la conciliación después de la compresión? Bueno, en este caso, no . La compresión ha eliminado toda esa rama, por lo que no se puede deshacer - esos datos han sido eliminados. Si hubiera habido otra versión con nombre en esa rama, entonces la compresión no habría destruido esa rama. Espero que a estas alturas esto tenga sentido.

¿Deberías hacer esto? Depende de usted, si no sabe lo que está haciendo, puede perder fácilmente datos después de una compresión.

Answer 2

Existe una herramienta llamada Geodatabase Toolset (GDBT), que es un plugin para ArcCatalog. Visualiza el linaje del estado y las versiones:

Descargue el GDBT aquí

Answer 3

A falta de conocer la versión y el db. aquí tienes una información inicial que te ayudará.
Administración básica
Aquí hay información sobre rec y Correo electrónico:
Así que si aplicas estos conceptos y utilizas el comando de cambios de versión todavía tiene la oportunidad de rechazar esos cambios cuando rec y publique por defecto.

No tienes tres copias de la misma base de datos.
Tienes una copia con versiones.
Si está administrando este db, debería dedicar tiempo (incluso dinero) y familiarizarse con todo esto.
La clase esri Flujos de trabajo de edición de versiones para la geodatabase multiusuario es gratuito y ayudará a algunos.
Pero el monte completo sería lo que yo recomendaría para una persona que administre cualquier tipo de flujo de trabajo de edición de sde versiones.
Esa clase es genial! para entender Flujos de trabajo de edición de versiones para la geodatabase multiusuario .

Answer 4

Tengo una manera "rápida y sucia". Cambia a la versión por defecto y edita algo sobre el polígono que se ha borrado. Entonces cuando reconcilies a la versión por defecto tendrás un conflicto. Haz clic con el botón derecho del ratón en el conflicto y dile que utilice el estado anterior a la reconciliación. A mí me funciona.

Answer 5

Sí, puedes hacerlo, pero tendrás que hacerlo usando SQL.

NO APRUEBO ESTO, HAZLO BAJO TU PROPIO RIESGO. HAGA SIEMPRE UNA COPIA DE SEGURIDAD DE SUS DATOS ANTES DE EDITAR MANUALMENTE EL SDE.

Puedes consultar la tabla sde.versions para obtener el state_id de la versión que has publicado con los cambios que quieres deshacer. Luego puedes ir a las tablas A y D y eliminar las entradas que coincidan con el state_id.

    SELECT *
    FROM SDE.VERSIONS
    WHERE NAME = 'Version of interest';

Ahora tienes el state_id de interés. Ahora necesita encontrar las tablas A y D para la clase de característica. Esto se hace consultando la tabla_registro. El valor será el registration_id. Así que para obtener las tablas A y D, sólo tiene que añadir el registration_id a la A y D.

    REGISTRATION_ID = 1
    A table would be A1
    D table would be D1

A continuación, consulte la tabla A y D y elimine las entradas que tienen el estado_id de la consulta anterior.

Para saber más sobre las relaciones padre e hijo, basta con consultar las siguientes tablas de sde.

    state_lineages
    versions
    states

Todos ellos tienen relación y deberían ayudarte a seguir la pelota que rebota.