ZODB.Versions.VersionString
Documentation
Versions provide support for long-running transactions. They extend transaction semantics, such as atomicity and serializability to computation that involves many basic transactions, spread over long periods of time, which may be minutes, or years.
Versions were motivated by a common problem in web site management. Often a web site must be changed in such a way that changes, which may require many operations over a period of time, must not be visible until completed and approved. Typically this problem is solved through the use of �staging servers�. Essentially, two copies of a web site are maintained. Work is performed on a staging server. When work is completed, the entire site is copied from the staging server to the production server. This process is too resource intensive and too monolithic. It is not uncommon for separate unrelated changes to be made to a web site and these changes will need to be copied to the production server independently. This requires an unreasonable amount of coordination, or multiple staging servers.
In our web application platform, we addressed this problem through long-running transactions, which we call versions. Changes made to a web site can be made to a version (of the web site). The author sees the version of the site that reflects the changes, but people working outside of the version cannot see the changes. When the changes are completed and approved, they can be saved, making them visible to others, almost instantaneously.
Bobo POS 2 included very low-level support for versions that was used by our web-application platform. In Z ODB 3, high-level version support is incorporated in the base system.
Versions require support from storage managers. Version support is an optional feature of storage managers and support in a particular database will depend on support in the underlying storage manager.
Implementation
VersionsStrings are simply string version name. An empty string is used to indicate non-version committed data.