Object versioning

Abstract

A repository contains multiple versions of an object, and any version of the object can be modified by a user, as and when necessary. A table for one object ('first object') that is contained in another object ('second object') has at least two columns, namely one column for a minimum version of the second object and another column for a maximum version of the second object. If a number of versions of the first object are responsive to a query, then one version of the first object is selected if a version of the second object that is responsive to the query happens to be in the range defined by the just-described minimum version number and the maximum version number. Depending on the embodiment, the second object can be an immediate parent of the first object, or can be an ancestor (also called “first class object”) of the first object that is not contained in any other object. In some embodiments, one or more attributes of the first object are stored in a first table along with a unique identifier and a version number. In addition, information on relations of the first object to other objects as well as an identity of a configuration (to which the current version of the first object belongs) are stored in a second table. Therefore, a pair of tables are used for each object, so as to decouple information that defines an object from information on relationships of the object. If a change happens in just the relationship of an object then no change is made to the table containing the definition of the object. Similarly, if a change happens in just the definition of the object, then no change is made to the table containing the relations of the object. Moreover, when a change happens to an object, if the object has a number of ancestors and decendants only an immediate parent of the object is updated, thereby to eliminate a versioning chain reaction (i.e. other objects are not affected).