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:

• Creating a representation is a schema change—Since schema changes cannot be versioned, a representation added to a versioned feature class will be visible in all versions. Similarly, removing a representation from a feature class will be reflected in all versions. Representations can only be created outside an edit session. Representation rule information is held in the nonversioned system table, so it persists across the database.
• Changing or creating a representation rule is a schema change—Any additional rule or change to the structure, property values, or field mappings of a representation rule is a schema change and will be reflected in all versions immediately. Representation rule information is held in the nonversioned system table, so it persists across the database. Representation rules can only be changed outside an edit session.
• Assigning representation rules to features is an attribute change—Representation rules are assigned to features through the Rule ID field. Assigning a different rule to a feature—or setting a feature to a null rule—is an attribute change. It will only be reflected in the current version. Conflicts can be resolved using standard reconcile and post procedures.
• A shape override is an attribute change—Shape overrides will only be reflected in the current version until reconcile and post is performed.
• Overriding a property of a representation rule is an attribute change—Overrides will only be reflected in the current version. Conflicts can be resolved using standard reconcile and post procedures.
• Converting a feature representation to a free representation is an attribute change—The process of creating a free representation will trigger a change in both the Rule ID field and the Override field. The Rule ID value is always -1 when a feature representation is a free representation. Conflicts can be resolved using standard reconcile and post procedures.

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

• Why is a column-level conflict raised when I override two different properties of a feature in two different versions?

  Confusion can occur when two separate properties are overridden in two different versions. A conflict will be raised if both overrides are stored in the Override field, which is the default storage location for all overrides. For example, a feature follows the Cart Track rule in version 1 and version 2. In version 1, the line width of the cart track symbol has been overridden for that feature. In version 2, only the color of the cart track symbol for that feature has been overridden, but the line width feature still follows the rule. Since both changes are held in the Override field, a conflict would be raised in reconcile using both row-level and column-level conflict resolution, even though the changes are not truly in conflict. To avoid this situation, a better practice is to map those properties that you are likely to be overriding to explicit fields. This will separate the changes into unique fields so that they won't be detected by column-level checking.

  Learn more about explicit fields

• I have a large production database with many versions and a long lineage. Do I have to unregister the feature class as versioned before I enable representations?

  Creating new feature class representations will add two new fields—Rule ID and Override—to the feature class table in all versions. If you made the representation by converting a symbolized layer, the Rule ID field will be populated in the current version only. The feature class representation itself will appear in all other versions, but the Rule ID values in those versions will all be NULL. In this case, it can be cumbersome to update the Rule IDs across all versions of the database. If your workflow permits, create representations prior to registering your database as versioned. This will be faster than creating representations on a versioned feature class, because the delta tables do not have to be populated. If all edits are posted to the DEFAULT version—or the database has been compressed to preserve edits—then unregister the data as versioned prior to creating new feature class representations. Creating a new representation will result in the creation of two new fields, RuleID and Override (change in schema), along with populating values into the RuleID field. If you create a new feature class representation in a child/descendant version, then, though the new fields are created in all other versions, the ancestor versions will not populate values into the RuleID field. It is good practice to create new feature class representations in the SDE.Default version so that the representation rule values present in the RuleID field get propagated across all descendant versions.

  Creating new representations for a feature class that is registered as versioned will be slower, as the RuleID field gets updated for all features, and the delta tables are thus updated as well. This process is time consuming and depends directly on the size of your database.