Ugh La respuesta es realmente complicada y requiere muchos antecedentes de ArcSDE, por lo que intentaré ser lo más breve posible.
Tenga en cuenta que me referiré a algunos diagramas del documento técnico de versiones súper impresionante que puede encontrar en el sitio de ESRI . Si se trata de versiones, le recomiendo que lo lea detenidamente.
Luego, debe comprender cuál es la relación entre un estado (es decir, un nodo del árbol de estado) y una versión con nombre (es decir, una etiqueta que apunta a un estado).
Una base de datos típica puede verse como el diagrama de estado a continuación:
Aquí, tiene cuatro versiones en la base de datos (Versión A, Versión B, Versión C y POR DEFECTO). Pero quizás, me estoy adelantando un poco. Comencemos con lo que es un estado .
Puede pensar en un estado como una "transacción", una unidad lógica que contiene varias ediciones en una o varias tablas. Puede incluir dos inserciones en "FeatureClass A", una eliminación de "Feature Class B" y una modificación (efectivamente, delete + an insert) a "Feature Class X". Todos agrupados en uno.
Veamos un diagrama de estado de ArcSDE pequeño y simple que comienza en la identificación de estado 0:
Si comienza en el estado 0 y realiza modificaciones en una o varias tablas en una operación de edición, creará un estado secundario 1 y lo convertirá en el ID de estado activo actual . Otro grupo posterior de ediciones creará el estado secundario 2. Si desea deshacer, no necesita modificar la identificación del estado de ninguna manera; todo lo que necesita hacer es cambiar la identificación del estado activo actual a 1 o 0 (dependiendo qué tan lejos quieres ir). Un rehacer es lo contrario: simplemente mueva el ID del estado activo actual hacia adelante, tan lejos como desee.
Así es como funciona deshacer / rehacer en el control de versiones de ArcSDE.
OK, sigue adelante. Digamos que desea hacer una edición permanente (es decir, desea guardar). ¿Que tienes que hacer? Bueno, guardar es solo tomar una etiqueta de versión y avanzarla a un estado en particular. Algo así como estamparlo y decir "así es como debe verse la Versión A". Entonces, si observa el primer diagrama, verá que tiene cuatro versiones con nombre .
- La versión B apunta al ID de estado 1
- La versión A apunta al ID de estado 3
- La versión C apunta al ID de estado 5
La versión "SDE.DEFAULT" apunta al ID de estado 4
Tenga en cuenta que este diagrama, a pesar de la creencia popular, no le dice nada sobre la relación lógica padre-hijo que tienen. La relación lógica padre-hijo para el primer diagrama podría verse así:
Esta es la relación padre-hijo que ve en ArcMap / ArcCatalog. Su propósito es restringir con qué versiones se puede reconciliar. En este punto, podrías (con razón) preguntarte, ¿por qué demonios necesito esto? La respuesta está en los flujos de trabajo de versiones . Resulta que las personas han estado usando el control de versiones durante 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 su pregunta hoy :)
Continuando ...
Bien, ¿qué más hacen estas versiones con nombre? Bueno, afectan cómo se comporta este proceso llamado compresa .
Comprimir se trata de obtener estados intermedios que pueden no ser necesarios y eliminar los innecesarios, así como combinarlos. Puede activar la operación de compresión ArcSDE a través de ArcCatalog, configurar un servicio que lo haga cada cierto tiempo, y algunas operaciones de edición de ArcMap activarán operaciones de mini-compresión (es decir, solo para ramas pequeñas que se están utilizando).
El diagrama de la izquierda muestra un árbol de estado antes de que se comprima, y el de la derecha lo muestra justo después de que se comprime:
Un concepto importante para entender (que me referiré a usted una vez que finalmente pueda responder a su pregunta) es que cada estado es un candidato potencial para ser comprimido, excepto los estados que tienen etiquetas (es decir, versiones con nombre) apuntadas a ellos.
Puede ver que antes de la compresa hay algunos estados adicionales innecesarios. De hecho, se eliminó toda la rama [3,4,5]. Si hubiera habido una versión con nombre en 5, el resultado final habría sido muy diferente.
Las operaciones de compresión están ahí para ahorrar espacio en su base de datos al eliminar registros que ya no necesita.
OK, sigue adelante.
El último concepto que debe comprender es la reconciliación , que es la fusión efectiva de dos ramas en una.
Así que volvamos a nuestro primer diagrama. Supongamos que desea conciliar la Versión A con SDE.DEFAULT.
Recapitulemos: cuatro versiones con nombre que apuntan a varios identificadores de estado. Entonces, lo primero que tenemos que hacer es crear un estado secundario en la versión de destino, de modo que creamos un estado secundario en la identificación de estado 4, en nuestro ejemplo, llamo a esa identificación de estado 20.
El siguiente paso es calcular las diferencias entre ambas versiones (los detalles son demasiado largos para esta publicación, pero puedo decirle que se hicieron con cursores de diferencia ) y luego aplicar esas diferencias a esa nueva identificación de estado 20 (línea azul).
Supongamos que decide hacer más ediciones o que encontró conflictos y está eligiendo filas de una versión u otra. No importa. Esas son solo ediciones nuevas, y se realizan dentro de una operación de edición, como estados secundarios debajo de la rama que fusionó. En este ejemplo, he realizado dos grupos más de ediciones consecutivas después de la conciliación.
Encantador.
Ahora diga que está listo para " publicar " la versión. Qué significa eso? Eso es solo agarrar las etiquetas y apuntarlas al mismo ID de estado. Aquí, voy a publicar 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 se ven iguales.
Bien, ahora puedo finalmente responder tu pregunta.
¿Puedes deshacer una publicación? La documentación de ArcGIS le dirá que no , no se meta con eso. 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 verdad, todo lo que se necesita es hacer una actualización de una de las tablas de versiones de ArcSDE : la tabla VERSIONS y modificar la entrada de la etiqueta (también conocida como versión con nombre). En nuestro ejemplo, señale la identificación de estado 21, y acaba de deshacer toda la operación de edición. Póngalo en 3, y simplemente deshizo toda la conciliación. Póngalo en 5, y ahora está en un lugar completamente diferente. Ya sea que haya o no conflictos, es irrelevante.
Por supuesto, esto supone que no ha ocurrido una compresa. Consideremos el caso en el que la compresión está ocurriendo exactamente al mismo tiempo que actualiza la tabla SDE. Recuerde, si usted u otra persona ejecuta una compresa después de publicar esto, así es como se ve el árbol:
¿Puedes deshacer la conciliación después de la compresa? Bueno, en este caso, no . La compresa ha volado toda esa rama, por lo que no puede deshacerla: esos datos se han eliminado. Si hubiera habido otra versión con nombre en esa rama, entonces la compresa no habría destruido esa rama. Espero que a estas alturas esto tenga sentido.
Entonces, ¿deberías hacer esto? Depende de usted, si no sabe lo que está haciendo, puede perder datos fácilmente después de una compresa.