FAQ: How Does the State Tree Change during an Edit Session?

Answer

During versioned editing, the geodatabase maintains the edits that have occurred during an edit session using geodatabase repository tables and user adds and deletes tables. The geodatabase repository tables maintain a logical organization of all the states in the geodatabase, called the state tree.

Using the following example, this document explains how the state tree changes during an edit session.

Example 1: Single user editing the GIS.EDIT version
An editor connects to the Enterprise Geodatabase in ArcMap, adds the STREETS feature class, and changes to the GIS.EDIT version. Before starting the edit session, the geodatabase repository tables maintaining information about the versioned environment contain the following information:
[O-Image] Repository tables 1

This results in the following state tree:
[O-Image] State tree 1

During the edit session, the geodatabase uses a private lineage for the edits that occur in the edit session. The version pointer do not move to a different state until the save operation occurs.

The editor starts an edit session and performs three edit operations on the STREETS feature class. Each edit is labeled with a new state_id and the information about the states is committed to the STATES and STATE_LINEAGES tables. The version being edited is not updated until the save operation.
[O-Image] Repository tables 2

By examining the information in the repository tables, the state tree can be created by tracing the lineage of the user’s edit session:
[O-Image] State tree 2

During the edit session, every edit operation is labeled with a state_id. The lineage for this ArcMap edit session is 0, 1, 2, 3. This lineage of edits offers the editor the ability to undo a prior edit. For example, if the editor realized that the feature that was deleted was incorrect, the editor could simply undo the last edit. At this point, the ArcMap edit session would simply reference the edits at state 1 and 2.

This example shows 'undo last edit':
[O-Image] State tree 3

The ArcMap edit session's lineage is now 0, 1, 2. The edit at state 3 is no longer part of the lineage and is removed from the adds and deletes tables and the geodatabase repository tables upon the next edit operation or save. If the editor decides to use the redo tool to redo the edit, before performing a new edit or saving, state 3 is included in the ArcMap edit session's lineage. Therefore, the lineage after the redo is 0, 1, 2, 3.

Next, the editor saves the changes. During the save the following actions occur:
1. The lineage is trimmed to reduce the number of rows in the repository and user tables.
2. The version is updated to reference the last state of the lineage.

The lineage of edits during the edit session is used to preserve the edit operations allowing the editor to 'undo' or 'redo' an edit. As the editor can not undo a saved change, upon the save, the geodatabase does not need to preserve the individual edit states. Instead the geodatabase trims the tables so that all the edits during the edit session are referenced to the last state to minimize the number of rows in the repository and user tables. Additionally the version must be updated to the final saved state in the lineage upon the save.
[O-Image] Repository tables 3

This example shows the resulting state tree after the save:
[O-Image] State tree 4

Upon the save, all the edits that occurred within the lineage (1, 2, and 3) are now referenced as occurring at state 3, allowing the geodatabase to remove states 1 and 2 from the geodatabase repository tables. The version that was being edited is updated to reference state 3 and any users who now connect to this version are now be able to see the edits performed by the editor.

Example 2: Two editors editing the GIS.EDIT version
Two editors connect to the Enterprise Geodatabase in ArcMap and change to the GIS.EDIT version. Both editors edit the STREETS feature class.

The state tree of this geodatabase currently is:
[O-Image] State tree 5

Both editors begin editing on the GIS.EDIT version. To support the individual edit sessions, each editor has a private lineage that is only available to the editor. The GIS.EDIT version remains at state 3 until the edit sessions are saved.

First, editor1 makes three changes to the feature class. The edit session's lineage is able to inherit the lineage from the parent state, therefore the repository tables contains the following information:
[O-Image] Repository tables 4

The corresponding state tree is:
[O-Image] State tree 6

Next, editor2 performs three edit operations. Editor2's lineage can not inherit the parent state's lineage name as this lineage is consumed by Editor1. Therefore, the geodatabase must branch the state tree to support Editor2’s lineage.
[O-Image] Repository tables 5

The corresponding state tree is:
[O-Image] State tree 7

The state tree shows that Editor1 and Editor2's edit sessions are maintained on separate branches of the state tree. Editor1's lineage is 0, 3, 4, 5, 6 and Editor2's lineage is 0, 3, 7, 8, 9.

Next, the editors must save their edit sessions; because this editor is the first to save, the save actions are the same as if this editor was the only editor editing this version. The geodatabase performs the following actions:
1. The version is updated to reference the last state of the lineage.
2. The lineage is trimmed to reduce the number of rows in the repository and user tables.
[O-Image] Repository tables 6

The corresponding state tree is:
[O-Image] State tree 8

The GIS.EDIT version is now referencing state 6 with a lineage of 0, 3, 6. The edit session lineage has been trimmed and the edit operations at states 4, 5 and 6 are now all referenced to state 6.

Next, Editor2 attempts to save. During this attempt, the geodatabase determines that the state the GIS.EDIT version is referencing has changed to state 6, therefore, the geodatabase must reconcile the edits on Editor2’s lineage to the lineage supported by the GIS.EDIT version. Implicitly, a reconcile occurs when the second editor saves on the same version. By default, the editor is warned that this reconcile has occurred. The warning message is:

"Your edits could not be saved because the target version has been updated since you started editing. These edits have been merged into your edit session. Review the changes and save again."

When the reconcile action occurs, all the edits from Editor2’s lineage are copied to a new state which is part of the GIS.EDIT lineage. The GIS.EDIT version still references state 6 because the reconcile action has not yet been saved.
[O-Image] Repository table 7

State tree after implicit reconcile:
[O-Image] State tree 9

After the implicit reconcile, state 10 has been added to the state tree as a child state of state 6. State 10 is part of the lineage that the GIS.EDIT version is referencing. Upon the implicit reconcile all the edit operations that occurred at state 7, 8, and 9 are copied to state 10 and Editor2’s edit session is now referencing state 10 which has a lineage of 0, 3, 6, 10. Editor2’s lineage includes state 6 allowing Editor2 to see what happened in Editor1’s edit session (state 6).

Notice that the GIS.EDIT version is still referencing state 6. In order for the GIS.EDIT version to reference state 10, Editor2 must save again. The second save moves the GIS.EDIT version to state 10.
[O-Image] Repository tables 8

State tree after saving:
[O-Image] State tree 10

The GIS.EDIT version now references the edits performed in Editor1's edit session and Editor2's edit session. Upon the next compress, the unreferenced states 7, 8, and 9 are removed from the geodatabase.

ArcMap provides editors with options to automatically save the changes after the implicit reconcile has occurred.

Article ID:000009156

Software:

ArcMap 8 x
ArcMap 9 x
Legacy Products

Get help from ArcGIS experts

Contact technical support

Download the Esri Support App

Go to download options

How does the state tree change during an edit session?

Answer

Discover more on this topic