International Business Machines Corporation

Charles S Tribolet

Mary C Lehner

Neal R Eisenberg

Robert L Huddleston

Gary R Karasiuk

John Marland Garth

Brian Thinh-Vinh Tran

Tony Kuen Lee

A versioned-data management system (VDMSMS) is provided with a method for determining candidates for promotion in association with a user task. The VDMS maintains a list of parts changed as a result of a user task, referred to as a promote group. Before performing any changes the user informs the VDMS which user task is to be associated with the changes. All parts subsequently changed are automatically placed by the VDMS in the promote group associated with the given user task. When the parts associated with a user task for a given variant level are promoted, an iterative process is performed to determine the complete set of parts that must be promoted in support of the requested promote. Initially the set includes those parts in the promote group at the given variant level. Then all the other promote groups are searched to determine whether they contain any of the parts at the given variant level that are already in this set. For any that do, the parts in those promote groups for the given variant level are added to the set of parts to be promoted.

Versioned-database management system in which tasks are associated with

A method is provided in a versioned database management system for allowing parts to be versioned according to different variant hierarchies, and for maintaining correct configurations of versions of parts as those parts are drawn down, changed, and promoted. Each version of a part is associated with a variant domain. Each variant domain is represented by a single variant hierarchy whose levels can be used to reference versions of parts in that variant domain and controls how versions of parts in that variant domain are drawn down, changed, and promoted. Variant domain default groups are provided so that tools may add new parts without specifying the variant domains to which the parts are to belong. In order to control which versions of parts and from which version domains are visible, variant maps are defined by the user installation. When a change is made for one configuration, it is simultaneously made in any other configuration identified by a variant map which includes the same variant ID. A variant map thus constructed is used by the VDMS to determine the variant hierarchy level to which any instances created belong, and to determine which instances in a promote group are promoted and to which hierarchy level they are promoted.

Variant domains and variant maps in a versioned database management

A versioned-data management system is provided with a method for detecting independent changes to a part when an attempt is made to promote a variant of the part. For each variant of a part, there is maintained two identifiers and a flag. The first identifier is the identifier of the last change to that variant. The second identifier is the last-change identifier of the variant which was the source of the drawdown. When the variant is successfully promoted, and there was not previously a variant at the level to which it is promoted, its drawdown-from identifier value is not changed. When the variant is successfully promoted, and there was previously a variant at the level to which it is promoted, the drawdown-from identifier is set to the drawdown-from identifier value of the variant which was previously at the level to which the promote is made. When the promote of a variant fails, the drawdown-from identifier is set to the last-change identifier value of the variant which is first in the search path beginning at the level to which the promote is being made. The flag indicates whether the variant can be promoted by normal means, or must be promoted using promote.sub.-- force. The identifiers and flag are used to identify independent changes and control data integrity in the VDMS at promotion time.

Detection of independent changes via change identifiers in a versioned

A versioned data management system is provided with a method for resolving sources and targets of relationships. For each entity instance, a lifetime ID is recorded. When the add interface is used to add an entity, a value is assigned to the lifetime ID, which value has never been used before for an instance of the entity type. When the update interface is used to update an entity, the lifetime ID is maintained unchanged. If the update results in a new version, the new version is given the same lifetime ID value as that for the version that was the basis for the update. If the delete interface is then used to delete the entity, and the add interface is later used to add an instance with the same part key, that instance will have a different lifetime ID. For each relationship instance, lifetime IDs are recorded for the relationship, its source, and its target. When the add interface is used to add a relationship, a value is assigned to the lifetime ID, which value has never been used before for an instance of the relationship type. Also, the lifetime IDs of the source and target of the relationship are recorded in the relationship instance. The lifetime ID of the relationship and the lifetime IDs of the source and target are maintained unchanged. If an update results in a new version of the relationship, the new version is given the same lifetime ID value as that for the version that was the basis for the update.

Growing community of inventors

Morgan Hill, CA, United States of America

Charles S Tribolet