Trabajar con representaciones en un entorno versionado

Para entender cómo trabajan las representaciones en un entorno versionado, es importante tener primero una comprensión sólida de los principios de la versión y de cómo se almacenan las representaciones de la clase de entidad dentro de la geodatabase.

Más información sobre la versiónMás información sobre cómo se almacenan las representaciones

¿Cómo trabajan las representaciones en un entorno versionado?

Las clases de entidades con representaciones participan en un entorno versionado al igual que las clases de entidades sin representaciones. Estas son algunas cosas claves que se deben considerar:

• Crear una representación es un cambio de esquema:Ya que los cambios de esquema no se pueden versionar, una representación agregada a una clase de entidad versionada estará visible en todas las versiones. Del mismo modo, quitar una representación de una clase de entidad se reflejará en todas las versiones. Las representaciones sólo se pueden crear fuera de una sesión de edición. La información de la regla de representación se guarda en la tabla del sistema no versionada, de modo que se mantenga en toda la base de datos.
• Cambiar o crear una regla de representación es un cambio de esquema:Cualquier regla adicional o cambio en la estructura, en los valores de propiedad o en las asignaciones de campos de una regla de representación es un cambio de esquema y se reflejará en todas las versiones de inmediato. La información de la regla de representación se guarda en la tabla del sistema no versionada, de modo que se mantenga en toda la base de datos. Las reglas de representación sólo se pueden cambiar fuera de una sesión de edición.
• Asignar reglas de representación a las entidades es un cambio de atributo:Las reglas de representación se asignan a las entidades a través del campo Id. de regla. Asignar una regla diferente a una entidad, o configurar una entidad a una regla nula, es un cambio de atributo. Sólo se reflejará en la versión actual. Los conflictos se pueden resolver usando procedimientos de conciliación y posconciliación estándar.
• Una excepción de forma es un cambio de atributo:Las excepciones de forma sólo se reflejarán en la versión actual hasta que se realice la conciliación y publicación.
• Invalidar una propiedad de una regla de representación es un cambio de atributo:Las excepciones sólo se reflejarán en la versión actual. Los conflictos se pueden resolver usando procedimientos de conciliación y posconciliación estándar.
• Convertir una representación de entidad a una representación libre es un cambio de atributo:El proceso de creación de una representación libre desencadenará un cambio tanto en el campo Id. de regla como en el campo Excepción. El valor Id. de regla es siempre -1 cuando una representación de entidad es una representación libre. Los conflictos se pueden resolver usando procedimientos de conciliación y posconciliación estándar.

Flujos de trabajo recomendados para utilizar representaciones en un entorno versionado

Situación 1

• La versión principal (versión de destino) cambia la ReglaID de representación de R a R* para una representación de entidad.
• La versión secundaria (versión de edición) edita la misma representación de entidad pero agrega una excepción de atributo, que se almacena en el campo Excepción como O*.
  • La versión secundaria se concilia contra la versión principal. Según cómo se definen los conflictos, obtendrá distintos resultados.
  • Nivel de fila: Ya que se edita la misma entidad en las dos versiones, se detecta un conflicto. Los conflictos se pueden resolver a favor de cualquier versión, según la preferencia. Por lo tanto, la representación final tiene ReglaID R junto con Excepción O* o ReglaID R* junto con Excepción O. Los resultados son coherentes.
  • Nivel de columna: Aunque se edita la misma representación de entidad, las ediciones se realizan en dos campos o atributos separados, llamados ReglaID e Excepción, y por lo tanto no se detectan conflictos. En la conciliación, la representación de entidad tiene una ReglaID igual a R* y una excepción de atributo O*. La representación de entidad tiene una excepción de atributo para una propiedad que no pertenece a la regla de representación con la que se representa. Los resultados son incoherentes.
  • Para evitar esta situación, utilice la opción row_level.

Situación 2

• La versión principal (versión de destino) cambia la forma de una representación de entidad o agrega una excepción de forma, que se almacena en el campo Excepción como O*.
• La versión secundaria (versión de edición) edita la misma representación de entidad pero agrega una excepción de atributo, que se almacena en el campo Excepción como O**.
• La versión secundaria se concilia contra la versión principal. Independientemente de la versión que elija para resolver los conflictos a su favor, obtendrá el mismo resultado.
  • Nivel de fila o nivel de columna: La misma representación de entidad se edita en las dos versiones. Además, las ediciones se realizan en la misma excepción de atributo. Aunque las excepciones de forma y atributo son dos entidades separadas, editarlas da como resultado el mismo campo Excepción. Se detectan los conflictos, y deberá mantener cualquiera de las ediciones, O* ó O**.
  • Solución: Almacene las ediciones de atributo en un campo explícito en lugar de almacenarlas en el campo Excepción. En la conciliación, si se selecciona la definición de nivel de columna, no tendrá ningún conflicto, ya que las ediciones se realizan en dos campos separados (campo Excepción y explícito). Como resultado, podrá guardar las dos ediciones.

Situación 3

• La versión principal (versión de destino) crea una excepción de atributo para una representación de entidad. El campo Excepción se actualiza a O*.
• La versión secundaria (versión de edición) edita la misma representación de entidad pero convierte la representación de entidad a una representación libre. El valor ReglaID cambia a -1, y un objeto de gráficos se introduce en el campo Excepción. Como resultado, este paso cambia los campos ReglaID e Excepción a R* y O**.
• La versión secundaria se concilia contra la versión principal.
  • Nivel de fila o nivel de columna: Hay un conflicto. Si elige resolver conflictos a favor de una versión principal (de destino), el resultado será incoherente. Existirá una excepción de atributo O* junto con un valor ReglaID igual a -1 o R*.
  • Solución: Elija resolver conflictos a favor de la versión secundaria para evitar resultados incoherentes. En este caso, guarde los cambios realizados por la versión secundaria e ignore cualquier edición realizada por la versión principal. Sin embargo, deberá tener en cuenta que las ediciones realizadas por la versión principal se pierden en este caso.

Situación 4

Si hay varios productos de mapa basados en varias representaciones de la clase de entidad que están presentes en la misma clase de entidad, utilice un escenario de Varios proyectos para editar los productos de mapa. Por ejemplo, cree un versión separada para cada producto de mapa: M1, M2, M3, y así sucesivamente. Después de editar estas versiones, reconcilie y acuerde con las versiones padre (o SDE.DEFAULT) utilizando la definición de nivel de columna y resuelva cualquier conflicto a favor de la versión de edición. Si desea escribir excepciones de atributo en un campo explícito en lugar del campo Excepción, cree campos explícitos por separado para cada producto de mapa.

Mejores prácticas

• ¿Por qué surge un conflicto de nivel de columna cuando invalido dos propiedades diferentes de una entidad en dos versiones distintas?

  Puede ocurrir una confusión cuando dos propiedades separadas se invalidan en dos versiones distintas. Surgirá un conflicto si las dos excepciones se almacenan en el campo Excepción, que es la ubicación de almacenamiento predeterminada para todas las excepciones. Por ejemplo, una entidad sigue la regla de Ruta en las versiones 1 y 2. En la versión 1, el ancho de la línea del símbolo de la ruta se invalidó para esa entidad. En la versión 2, sólo se invalidó el color del símbolo de la ruta para esa entidad, pero la entidad del ancho de la línea aún sigue la regla. Ya que los dos cambios se mantienen en el campo Excepción, surgiría un conflicto en la conciliación al utilizar la resolución de conflicto de nivel de fila y de nivel de columna, aún cuando los cambios no están completamente en conflicto. Para evitar esta situación, una mejor práctica es asignar esas propiedades que probablemente invalidará a los campos explícitos. Esto separará los cambios en campos únicos para que no se detecten mediante la verificación de nivel de columna.

  Más información sobre los campos explícitos

• Tengo una gran base de datos de producción con varias versiones y un linaje largo. ¿Tengo que dar de baja la clase de entidad versionada antes de habilitar las representaciones?

  Crear nuevas representaciones de la clase de entidad agregará dos nuevos campos, Id. de regla e Excepción, a la tabla de la clase de entidad en todas las versiones. Si creó la representación al convertir una capa simbolizada, el campo Id. de regla se completará solamente en la versión actual. La representación de la clase de entidad aparecerá en todas las demás versiones, pero los valores de Id. de regla en esas versiones serán todos NULOS. En este caso, puede ser difícil actualizar los Id. de regla en todas las versiones de la base de datos. Si su flujo de trabajo lo permite, cree representaciones antes de registrar su base de datos como versionada. Esto será más rápido que crear representaciones en una clase de entidad versionada, porque las tablas delta no se tienen que completar. Si todas las ediciones se publican en la versión PREDETERMINADA, o la base de datos se comprimió para preservar las ediciones, dé de baja los datos como versionados antes de crear nuevas representaciones de la clase de entidad. Crear una nueva representación dará como resultado la creación de dos nuevos campos, ReglaID e Excepción (cambio en el esquema), junto con el relleno de los valores en el campo ReglaID. Si crea una nueva representación de la clase de entidad en una versión secundaria/descendiente, entonces, aunque los nuevos campos se creen en todas las demás versiones, las versiones principales no completarán los valores en el campo ReglaID. Es buena práctica crear nuevas representaciones de la clase de entidad en la versión SDE.DEFAULT para que los valores de la regla de representación presentes en el campo ReglaID se propaguen por todas las versiones descendientes.

  Crear nuevas representaciones para una clase de entidad que se registra como versionada será más lento, ya que el campo ReglaID se actualiza para todas las entidades, y, por lo tanto, las tablas delta también se actualizan. Este proceso tarda mucho tiempo y depende directamente del tamaño de su base de datos.