Home    |    Concepts   |   API   |   Samples
Concepts > Versioning > Editing Workflows
Multiple-tier Version Tree

More complex projects will require a more elaborate workflow structure than that provided by either the direct editing or the two-tier approach. These projects may be further divided into multiple functional or geographic units from which a more complex versioning hierarchy will develop. For example, a project to design and construct a new shopping mall might have distinct construction phases: subdivided into east and west sections or subdivided by construction activities, such as building, gas, water or electricity installations, or landscaping.

For larger projects that will involve many editors, often working on different teams and on numerous discrete units of work, a multiple-tier version tree is an effective way to organize the workflow. The teams working on different aspects of the same project create their own version to maintain a private view of their updates. Once the project has been completed, the versions can be reconciled and posted back to the DEFAULT version and become an integral part of the published database.

Pros

  • Supports complex projects.
  • Supports long transactions, which span many edit sessions.
  • Supports automated batch reconcile and post processes.

Cons

  • First-level versions cannot be posted to the DEFAULT version until the second- and third-level versions have been posted to their respective parents.
  • Reconciling and posting can only take place between versions in the direct path—It is not possible to reconcile and post across version paths.
  • Maintaining a complex version tree has some associated performance costs—The more rows in the version delta tables, the greater the potential impact on query performance.
feedback | privacy | legal