GEOG 868
Spatial Database Management

Merging Changes and Resolving Conflicts

PrintPrint

Merging Changes and Resolving Conflicts

When a feature class is registered as versioned, the dbo superuser is made owner of the DEFAULT version and permission to work with that version is set to Public. The Public permission setting means that any other user can both view and edit the DEFAULT version. This type of permission may not be ideal though, particularly if you want to avoid mistaken edits from being propagated to the base feature class. One way to safeguard against this happening is to set permission on the DEFAULT version to Protected. This allows anyone to create their own child versions based on DEFAULT, but only the dbo user can post changes to the DEFAULT version.

A. Changing permissions on the DEFAULT version

As the dbo user is the owner of the DEFAULT version, only the dbo user can change permission on that version. So the first step we'll need to take to alter permissions is to open up a connection through the dbo user.

  1. In a remote desktop connection to your instance, open ArcGIS Pro to a new project.
  2. Create a new connection to the database through the dbo user called dbo_egdb. (Recall, this is done using Operating system authentication.)
  3. Through the dbo_egdb connection, add the us_state_1790 feature class to the map. You should be viewing the feature class through its DEFAULT version, which you can confirm by clicking the List By Source button in the Display pane.
  4. Right-click on the dbo.DEFAULT heading above the us_state_1790 layer entry and select Manage Versions.  Each of the three versions of the us_state_1790 feature class should be listed.
  5. Select the DEFAULT version, and note that the Access on the DEFAULT version is set to Public.
  6. Change the Access from Public to Protected.
  7. Save the change you just made.
  8. Close the Versions view.

B. Reconciling and posting the census user's changes

Synchronizing the changes between two versions of the same feature class requires the passing of edits in two directions. These transfers happen through operations called reconcile and post:

  • reconcile - edits that exist in the parent version but not the child version get transferred from the parent to the child
  • post - edits that exist in the child version but not the parent version get transferred from the child to the parent

Both reconcile and post operations must be carried out while viewing the child version.

  1. Click on the DEFAULT heading in the Display pane to highlight/select it.
  2. Click the Change Version button under the Versioning tab and select the Statehood_edits version.
    Click OK.  You should see the Virginia/Kentucky split in this version.
  3. Click the Reconcile button under the Versioning tab. In the Reconcile dialog, you should see that DEFAULT is already selected as the Target Version. You are also presented with questions on how you want to deal with conflicts between the two versions. A conflict occurs when the same feature has been updated in both the edit and target versions.

    The first of these questions asks whether you want to resolve conflicts in favor of the target version or the edit version. Let's stick with the default (in favor of the edit version). If conflicts are found, we'll have an opportunity to review them and settle the conflict however we like anyway.

    The second question asks whether you want to define conflicts by object/row or by attribute/column. Let's go with by object.  The by column option might be used in a situation in which one user was responsible for making geometry edits and another user for attribute edits.
  4. Click OK to initiate the Reconcile between the Statehood_edits and DEFAULT versions. In this case, no changes will be transferred from DEFAULT to Statehood_edits since DEFAULT has not changed since Statehood_edits was first created.

    After the Reconcile is complete, the Post button (on the ribbon next to Reconcile) is enabled.
  5. Click the Post button.  The Post button will become disabled when the process is complete. The edits that were made to the Statehood_edits version (the Kentucky-Virginia split) will be transferred to DEFAULT.  (You could confirm this by switching back to the DEFAULT version.)

    You'll now perform a reconcile and a post between Moe's edits (stored in the Statehood_changes version) and DEFAULT.

C. Reconciling and posting Moe's changes

  1. Again, click on the version heading above the layer's entry in the Display pane.
  2. Click the Change Version button on the ribbon under the Versioning tab.
  3. In the Change Version dialog, switch to the Statehood_changes version, and click OK.

    When the Statehood_changes version is mapped, you should see the Northwest and Southwest Territories disappear (they were deleted in this version) and a more accurate eastern boundary for Kentucky.
  4. Click Reconcile, and as you did above, choose to resolve conflicts in favor of the edit version and by object.  Click OK to initiate the reconcile process.
    In this case, the Reconcile operation will find changes to transfer from DEFAULT to the Statehood_changes version, since DEFAULT was just updated with edits made by the census user.

    As the software attempts to transfer those changes to the Statehood_changes version, you'll see that it detects conflicts.
  5. In the Reconcile dialog, click Yes to review the conflicts.

    Note that a similar view to what we experimented with earlier appears, with a list of conflicts on the left and a table providing data such as shape area/length for the two conflicting versions of the object on the right.  In the bottom of the view, a Conflict Display can be expanded to display the selected conflicting geometries in map form.

    There is a single conflict in this case — Update-Update (1).
  6. Expand the Update-Update list, and click on the feature ID of 6.
    Note that the conflicting properties (in this case, the Shape) are shown with red highlighting.

    The dialog shows Property values for four different representations of the conflicting feature:
    • Current- this is how the feature is currently going to be resolved.  If you chose to resolve in favor of the edit version, the values in this column will be the same as those in the next column.
    • Pre-Reconcile - this is how the feature is stored in the edit version (i.e., as it was drawn by Moe).
    • Target- this is how the feature is stored in the DEFAULT version.
    • Common Ancestor - this is how the feature looked before any edits were made.
  7. If you haven't already done so, expand the Conflict Display. After a moment, you'll see a side-by-side comparison of the Current and Target representations. One could use the tools beneath each map to inspect each representation in an attempt to decide how to resolve the conflict.
  8. Moe created the Virginia/Kentucky boundary more carefully, so we want to accept his edit.

    Back in the table that lists which properties have conflicts, right-click on the Shape Property and note there are options for replacing the value of the Shape attribute with the Pre-Reconcile version, the Target version, or the Common Ancestor version. There is also a "split the difference" option (Merge Geometries).

    Select the Replace With Pre-Reconcile Version option.  (There will be no noticeable change in the Conflicts view.)

    Close the Conflicts view.

    If there were more Conflicts (1/X), you would navigate to the next one and repeat the review process. In this case, there was only one so we can close the Conflicts view.

    Looking again at the map, you'll probably notice a problem.  There are now two Virginia/Kentucky boundaries appearing -- one from each of the editors.  There's actually an explanation for what's happened here.  We just reconciled Moe's version against the DEFAULT version -- i.e., said to transfer features from DEFAULT to Moe's version.  The Virginia polygon appeared in the Conflicts view because that feature (having OBJECTID of 6 in both versions) was different.  We said to go with Moe's version of Virginia, and if you have Virginia selected you should see that the selection symbol follows Moe's boundary, not the census user's.  But what's happened is the census user's Kentucky polygon has been added to Moe's version because Moe's Kentucky feature has a different OBJECTID than the census user's (418 vs. 18 when I went through this process).  Ideally, we would have seen the Kentucky polygons in the conflict list as well, but we couldn't because the conflict detection algorithm compares geometries that share the same OBJECTID.

    Why did the two Kentucky features have different OBJECTIDs?  Well, if you think this through, there's not really any way for the software to know that the two editors were creating the same new feature.  OBJECTID is the primary key in the us_state_1790 table, so all new features are given a unique OBJECTID value.

    So, we'll need to clean up this unwanted Kentucky feature before Posting changes to DEFAULT.  
  9. Open the us_state_1790 attribute table and scroll to the bottom.  You should see the two Kentucky features.
  10. Select the features one at a time until you've determined which is the unwanted one.
  11. With that feature selected, hit the Delete key on your keyboard.

    With that unwanted Kentucky removed, you're now ready to post Moe's changes to DEFAULT.
  12. Return to the Versioning tab and click the Post button.

    The two territories that were part of the original feature class (in the DEFAULT version) have now been removed as a result of this post.  And the Kentucky and Virginia features that had been posted to DEFAULT by the census user have been replaced by Moe's.  

    Note: In a scenario like this, setting up topology rules (e.g., no overlapping polygons) in addition to using versioning might be needed to avoid problems!

D. Reconcile census user's version against DEFAULT again

To summarize, in Part B, you performed a reconcile and a post between the census user's version and DEFAULT. Then, in Part C, you performed a reconcile and a post between Moe's version and DEFAULT. In Part C, edits made by census have been propagated to Moe's version -- and were rejected -- by virtue of the fact that census had just posted changes to DEFAULT. However, at this point, the changes that were made by Moe have not been propagated to the census user's version. To do that, the census user would need to (a) do another reconcile, or (b) delete the Statehood_edits version and re-create it.
Let's go with option a.

  1. Switch the feature class version again to Statehood_edits.
  2. Perform a Reconcile.  Because we now know that the DEFAULT version contains the desired geometries, choose to resolve conflicts in favor of the target version.  You should see that all of the edits that were made in Moe's version are now propagated to the census user's version. There is no need to do a Post at this point, since there are no edits that weren't already posted in Part B.
  3. Save your edits.

A few final points on versioned editing:

  • You might find it worthwhile to go through a similar "two users performing the same edit" exercise, but simply editing existing features.  For example, you might turn on Map Topology as discussed in Lesson 5, and make further edits to the Kentucky-Virginia boundary, moving some of the vertices to alter the shapes of both polygons.  Then go through the Reconcile-Post process and resolve the conflicts however you see fit.  You'll find that because your modifications involve only existing features, the conflict resolution process will go more smoothly, not requiring the sort of "manual intervention" we went through with our splitting Virginia exercise.
  • That said, even if the Reconcile-Post process went smoothly for all editing scenarios, it's still recommended that you try to avoid having to resolve conflicting edits altogether by setting up clearly divided areas of responsibility for the various members of your editing team.
  • If you do incorporate versioned editing into your workflow, note that the size of the delta tables can have a significant impact on performance (e.g., feature drawing and querying).  For this reason, it is important to regularly compress the database (the Compress tool is documented here [https://pro.arcgis.com/en/pro-app/tool-reference/data-management/compress.htm]) and update the database statistics as discussed in the previous lesson. Further information on versioned editing workflows can be found in this Esri white paper [http://downloads.esri.com/support/whitepapers/ao_/Versioning_Workflows_2.pdf].

Through this short tutorial, you've seen how an organization can carry out edits to its data in a way that balances the need for preserving data integrity with the need to keep the data as up-to-date as possible.

Move on to the next page to access the graded activity for this lesson.