| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 9)

Working with Modularized KBs

 A modularized KB contains one or more modules. When you save a modularized KB file, G2 saves one module per file.

As explained below, if the current KB contains modules that are inconsistently modularized, and you save the KB, G2 requires that the entire current KB and all its modules be saved into one KB file. In this case, the KB file contains knowledge about more than one module.

Loading a Modularized KB

If you direct G2, interactively or programmatically, to load a KB file, G2 first attempts to load all KB files that the specified KB directly or indirectly requires. Indirectly required KB files are files that contain modules that are directly required by submodules in the hierarchy.

When loading a KB, G2 does the following:

  1. Traces down the module hierarchy of the top-level module in the specified KB until it finds a KB whose module does not directly require another module.

  2. Loads that KB.

  3. Loads, in turn, the KB that directly requires the KB already loaded.

  4. Continues marching up the hierarchy until it loads all directly required modules of the top-level module.

The following figure indicates the order in which G2 loads the modularized KBs that are directly and indirectly required by the top-level module named top:


No matter how many modules directly require a particular module, G2 loads that module only once.

Loading Modularized KBs and Detecting Conflicts

After you direct G2 to load a modularized KB, as G2 loads the modularized KBs that form a particular module hierarchy, G2 actually performs one load operation and one or more merge operations. First, G2 loads the KB whose module requires no other modules, then G2 merges one or more KBs into the current KB.

Because G2 actually performs merge operations to load the second through last KBs into the current KB, it is possible for G2 to detect conflicts among the definitions found in the various KBs. Therefore, when loading a KB that directly require modules in other KBs, you might want to check the automatically resolve conflicts box in the Load KB dialog.

Tip: For information on whether to select the automatically resolve conflicts check box and how to respond to a conflict workspace, see Detecting Conflicting Class Definitions.

Loading a Particular Version of a KB File

Your application development team might work with different versions of the same KB file, with each version stored in different directories. If a KB directly requires a module located in a particular version of another KB, you can use either of two techniques to ensure that a particular KB file is loaded:

Automatic Loading of Directly Required Modules

When a module stored in one KB directly requires a module stored in another KB, and you load the first KB, G2 automatically loads the directly required module's KB first, loads the requiring KB next, and so on, until the specified KB is loaded.

By default, G2 looks for a KB file with the same name as the directly required module. For example, if you load a KB that contains a module named top, and top directly requires another module named classes, then G2 attempts to find the module by searching for and loading a KB file named classes.kb in the same directory where the KB file containing the module top resides.

Tip: You can optionally use a module map file or module search path, to direct G2 where to find directly required modules. For more information about using a module map file, see Using a Module Map File to Load and Save a KB. For more information about using a module search path, see Using a Module Search Path to Load KB Files.

Merging a Modularized KB into the Current KB

Merging any KB file means to read a stored KB and to add its knowledge to the current KB. You can merge any KB into the current KB.

To merge a KB interactively:

G2 automatically selects the merge in this KB option in the save KB workspace.

To merge a KB programmatically:

Merging Directly Required Modules

 When you merge a modularized KB, G2 automatically merges other KBs that the specified KB directly or indirectly requires. This is also true when you load a KB that requires other modules. G2 selects the other KBs to merge as described in Loading a Modularized KB.

Installing System Tables of a Merged Modularized KB

When you merge a KB, you can either install or not install its system tables into the current KB. Installing the system tables of a merged KB causes the module described in the Module Information system table of the merged KB to become the top-level module in the resulting current KB.

To install the system tables of a merged KB, check the merge in this KB and install its system tables check box, as shown in this figure:


If you merge a modularized KB without installing its system tables, the resulting KB contains the merged modules, but they may not participate in the current KB's module hierarchy.

For example, if the current KB contains no top-level module, after merging a KB without installing its system tables, the Inspect facility shows that there is no module hierarchy, because there is no top-level module:


Because the resulting KB has no top-level module, the merged modules are not directly required, and the resulting KB is inconsistently modularized.

If the current KB contains modules, the result of merging a KB and installing its system tables depends upon whether the current KB already has a top-level module, as follows:

Ignoring Modules With Duplicate Names

If a merged KB directly requires a module with the same module name as a module already in the current KB, G2 does not attempt to load that module again. G2 ignores the second and subsequent attempts to load a module with the same name, even if those modularized KBs reside in different directories.

When G2 ignores merging a module in this fashion, G2 places a message on the Operator Logbook, such as the follows:


In this example, if your current KB is modularized and contains the module uilroot, and you merge another KB whose top-level module classes also directly or indirectly requires a module named uilroot, G2 does not attempt to merge another KB, which may be located in the same directory, and which also contains a module named uilroot.

Merging a Particular Version of a KB

As explained in Loading a Particular Version of a KB File, you can also merge a particular version of a KB by defining a module search path or creating a module map file.

For more information, see Using a Module Search Path to Load KB Files and Using a Module Map File to Load and Save a KB.

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 9)

Copyright © 1997 Gensym Corporation, Inc.