Working with representations in a versioned environment

To understand how representations work in a versioned environment, it is important to first have a solid understanding of the principles of versioning and of how feature class representations are stored inside the geodatabase.

Learn about versioningLearn about how representations are stored

How do representations work in a versioned environment?

Feature classes with representations participate in a versioned environment much the same as feature classes with no representations. Here are some key things to consider:

Recommended workflows for using representations in a versioned environment

Scenario 1

  • Parent version (target version) changes the representation RuleID from R to R* for a feature representation.
  • Child version (edit version) edits the same feature representation but adds an attribute override instead, which gets stored in the Override field as O*.
    • Child version is reconciled against parent version. Depending on how the conflicts are defined, you will get different results.
    • Row level: Since the same feature is edited in both the versions, a conflict is detected. Conflicts can be resolved in favor of either version, depending on the preference. Thus, the final representation has either RuleID R along with Override O* or RuleID R* along with Override O. The results are consistent.
    • Column level: Though the same feature representation is edited, the edits are made in two separate fields or attributes—namely RuleID and Override—and therefore, no conflicts are detected. On Reconcile, the feature representation has a RuleID equal to R* and attribute override O*. The feature representation has an attribute override for a property that does not belong to the representation rule it is being represented with. The results are inconsistent.
    • To avoid this situation, use the row_level option instead.

Scenario 2

  • Parent version (target version) changes the shape of a feature representation or adds shape override, which gets stored in the Override field as O*.
  • Child version (edit version) edits the same feature representation but adds an attribute override instead, which gets stored in the Override field as O**.
  • Child version is reconciled against parent version. Regardless of which version you choose to resolve the conflicts in favor of, you will get the same result.
    • Row level or column level: The same feature representation is edited in both versions. Also, edits are made to the same attribute override. Though shape and attribute overrides are two separate entities, editing these saves results into the same Override field. Conflicts are detected, and you will get to keep either one of the edits, O* or O**.
    • Workaround: Store the attribute edits in an explicit field instead of storing them in the Override field. At reconcile, if column-level definition is selected, then you will not have any conflicts, since the edits are made in two separate fields (Override and explicit field). As a result, you will be able to keep both edits.

Scenario 3

  • Parent version (target version) creates an attribute override for a feature representation. Override field gets updated to O*.
  • Child version (edit version) edits the same feature representation but converts the feature representation to a free representation. The RuleID value changes to -1, and a graphics object gets introduced into the Override field. As a result, this step changes both the RuleID and Override fields to R* and O**.
  • Child version is reconciled against parent version.
    • Row level or column level: There is a conflict. If you choose to resolve conflicts in favor of parent (target) version, then the result will be inconsistent. An attribute override, O*, will exist along with a RuleID value equal to -1 or R*.
    • Workaround: Choose to resolve conflicts in favor of the child version to avoid inconsistent results. In this case, keep the changes made by the child version and ignore any edits made by the parent version. However, you should note that the edits made by the parent version are lost in this case.

Scenario 4

If there are multiple map products based on multiple feature class representations that are present on the same feature class, then use a Multiple Project scenario to edit the map products. For example, create a separate version for each map product: M1, M2, M3, and so on. After editing these versions, reconcile and post with the parent versions (or SDE.Default) using column-level definition and resolve any conflicts in favor of the edit version. If you want to write attribute overrides to an explicit field instead of the Override field, then create separate explicit fields for each map product.

Best practices

Related Topics

3/5/2014