FAQ: What do common versioning terms mean or is there a versioning glossary?
What do common versioning terms mean or is there a versioning glossary?
What is a version?
A version is simply a user defined name which references a geodatabase state. When accessing a versioned geodatabase, you are working with a version of the geodatabase.
Versions differentiate only by the content of the rows for each objectclass. The schema for each versioned objectclass is the same across all versions.
When accessing a versioned objectclass, the geodatabase constructs a query in the underlying database which assembles a result set derived from the business and delta tables based upon the state of the database the version references.
What is a state?
A versioned geodatabase state references edits which have occurred in the geodatabase for a specific edit operation or collection of edit operations. All versioned edits that occur are uniquely identified with a state identifier. State 0 is defined as the base state and every geodatabase will have a state 0. All records within the base state reside or are physically stored in the business table and are accessible to all versions. When a feature class has not been edited or is being edited with non-versioned editing, all records reference state 0. If the feature class is registered as versioned and has been edited, the edits are preserved and maintained in the delta tables and are referenced with specific state IDs.
What is a lineage?
A lineage is a collection of geodatabase states representing the changes through time. Geodatabase states have a logical relationship between parent and child states. As changes are made in the versioned environment, the edits are preserved in the delta tables and labeled with a state ID. The lineage maintains all the edits that have occurred in the branch of the state tree back to state 0. Using lineages, the geodatabase can support multiple editors as each editor's changes maintain a unique lineage until such time as the lineages are merged together, such as when reconciled and posted.
What are delta tables?
Versioned editing preserves changes made by all users in two delta tables per table. Each multiversioned table has its own supporting delta tables, which are owned by the same DBMS user that owns the original object. All edits to a multiversioned table are recorded in the same delta tables, regardless of which user makes the edit.
One delta table is called the adds table, and the other is the deletes table. The names of these tables begin with either an 'A' or 'D', respectively, and are often called the A-table and D-table for short. As its name implies, the Adds table stores new rows inserted into the multiversioned table, as well as updated copies of existing rows. Likewise, the Deletes table stores references to old rows deleted from the multiversioned table.
What is a reconcile and post?
When two different branches of the state tree are merged together the process is performed through a reconcile. If the objective is to synchronize the two versions after the reconcile, this is performed via a Post. An implicit reconcile occurs if multiple people are editing the same version. When editors are editing their own versions, the process of merging versions is performed explicitly through a reconcile.
What is a reconcile?
The reconcile process is responsible for discovering the differences between two branches of the state tree and copying the edits from one branch to the second branch. Differences are defined as any updated, inserted or deleted features between the two branches. Once the differences have been discovered, the non-conflicting changes from the edit branch of the state tree are copied to the target branch of the state tree. If conflicts are detected, the user is given an opportunity to review the conflicts and resolve the differences. Once conflicts are resolved the reconciling user is able to perform a post.
The reconcile is an edit operation in the edit session but can not be undone. Once the reconcile has occurred, save the edit version or perform a post. If the edit session is exited without saving or posting, the edit session rollbacks to the last saved state.
What is a post?
Post moves the target and edit version to the final state of the edit session after reconcile and conflict resolution. The post operation simply updates both versions to reference the same database state.
If the new option in 9.2 to register the table with the move to base option if the post occurs on the DEFAULT version is selected, then during the post, all edits that are part of the DEFAULT version's lineage are moved back to the business or base table. At this point, these edits now exist at state 0 and be available to all versions.
If the table is archive enabled, which is also new functionality with ArcGIS 9.2, during the post to the DEFAULT version, the edits that are part of the DEFAULT lineage are copied to the archive class. All the archived edits are identified with the time of the post action.
What is a compress?
Compressing the database removes un-referenced rows from the geodatabase repository tables and the user editing tables. It is natural to have un-referenced states in the Geodatabase. Actions which cause un-referenced states include:
· Reconciling and posting results in the edit sessions branch becoming un-referenced. During a reconcile, all the edits on the edit sessions branch are copied to the target branch. Once the reconcile has been saved or posted the prior branch is no longer referenced by a lineage and is removed by the compress.
· Deleting a version removes the reference to it's state and lineage. Any states that were only referenced by this version and it's lineage are removed during the compress.
· If the client or the server crashes during an edit session, any edits that were not saved become un-referenced in the state tree. These edits can not be reinstated and are deleted during a compress.
What is a trim?
During an edit session, each edit is referenced with a unique state ID. The edit session maintains a lineage of edits, or all of the edits that have occurred during the edit session, to allow editors the ability to perform undo and redo.
During a save, the geodatabase trims the edits within the edit session's lineage to reduce the number of states in the geodatabase. During the trim multiple steps occur:
· Any objects that were updated multiple times within the edit session, which subsequently have many records in the A and D tables, are reduced to the final representation of the object for the edit session.
· The intermediate states are removed from the STATES, STATE_LINEAGES and MV_TABLES_MODIFIED tables, reducing the complexity of the state tree.
After the save, an editor can not undo the last edit. As the editor continues editing, a new edit session is started and each edit is preserved to a unique state ID, allowing the editor to undo back to the last save operation.