MetaInfo Section

Explanation of the MetaInfo section

'MetaInfo' section
For each class is required:

• an entry describing the class (Class / Syntax: ClassEntry)
• possibly further information on persistent storage (File / Syntax: FileEntry, Storage / Syntax: StorageEntry)
• Specification for plug-in DLLs with code for further model classes

The following figure shows for a class A the interaction between the information from CLASSIX.INI, a creator function A::New() and the object manager, when the latter creates an instance of a class A:

Class
generates an object CX_META_CLASS, which contains information about a class The following parameters must be specified:

• the name of the class
• an integer representing this class in the ClassiX® system
• the name of a metafile (see below)
• the name of the base class
• Bitpattern to control insertion into REP collections - If no BitPattern is specified, then 1 is assumed. So new objects of the class are only inserted into the REP of the class itself.
• Cluster(s) - requires that each persistent object of the class is stored in a separate cluster. The cluster size n is without meaning from ObjectStore 6.0 on: Specify Cluster(1)
• Docu(n) refers to the CyberEnterprise® documentation file of this class

To specify the inheritance path completely, base classes are often entered from which objects are never created. For these classes the meta file specification can be omitted. The derivation of all classes of CX_CLASS is known to the ClassiX® system a priori, i.e. even if CX_CLASS was not entered in CLASSIX.INI.

At this point, the term 'class' is used in a slightly broader sense: In addition to the term 'class' in C++ or Java, one can imagine a classification of objects, which leads to a further subdivision. With the keyword

PseudoClass
the objects of a C++ class can be divided into subclasses. The parameters are the same as for Class.

file
creates an object of the class CX_META_FILE. As the name suggests, this object provides information about how the objects are stored in the database. The main content is a vector that points to n storages . This organisation reflects the logical division of the database into layers (the layer selects the currently active storage). The parameters to be specified are:

• a unique name
• a list of storage names

Note: A maximum of²¹⁵ storages per file may be specified.

After names for the last storage specification the ellipse can be... after names. This notation saves the constant repetition of the same parameter if the same storage specifications are to apply to all (now following) layers:

The last storage definition of the file statement is repeated as many times as the file statement with the most storages specifies; from

File(fName1, stg0, stg1, stg2, stg3)

File(fName2, stga, ...)

will be

File(fName1, stg0, stg1, stg2, stg3)

File(fName2, stga, stga, stga , stga)

The parameter STOP is only meaningful in connection with the AutoLayer instruction and is explained there.

Storage
generates an object of the class CX_STORAGE. Here it is defined how the objects are stored in the object-oriented database ObjectStore.
parameters are:

• a unique name
• the physical database
• the segment(s) in which objects are to be saved
• A list of names of the root EntryPoint collections (= domains- maximum 15).
• a list of segments in which the Root Entry Point Collections are stored
• a tuple of names of a collection for logically deleted items (trash of the database) and the segment for this collection
• whether the object should be saved as a slot like an independent object (SeparateSlots) - optional

Reference to the physical database is made with

• Specification of the path
• the name of an environment variable that contains the current path to the database at startup
• DB(k), i.e. a reference to the Statement Database(..., k)

The segment specification controls the location in the database (the page) where the object is stored. The different variants - 1 segment, 2 segments, no segment at all - allow a fine-tuning of the clustering strategy when creating or copying an object with CreatePersObject / CopyPersObject instruction.

Segment
This instruction is required if further properties of a segment beyond the mere name are to be defined.
The first parameter is the segment name, then the following information is possible:

Database(k, name)
describes a physical database and assigns it an integer number k. With DB(k) you can refer to this database in the storage statements. Name is the complete or relative path to the database file, or the name of an environment variable, whose value then refers to the database file when the ClassiX® system is started.

Note: It is not allowed that different storages refer to the same physical database in different ways, e.g. using different environment variables or using different but equivalent path specifications.
When starting the ClassiX® system, such ambiguities are discovered.

AutoLayer
If a logical database is to be described which

• consists of many, in principle identical layers
• and assigns a separate physical database to each layer,

the constantly repeating specifications for file and storage can be generated with the AutoLayer instruction.

IndexCopy(FLAT | DEEP)
This parameter controls database indexes with the COPY_KEY option. The default assumption is DEEP.

Attention: before Dll-version 212701 the behaviour was undefined in case of missing information.

Note: Changing from FLAT to DEEP or vice versa is only possible if all database indexes have been deleted first. Afterwards the desired mode is entered in the .ini file and all indexes are rebuilt.

Scheme
Only for ObjectStore 5.x: Here the path of the schema database of ObjektStore is specified. As with all path specifications, the identifier CX_ROOTDIR is replaced by the path to the CLASSIX root directory.

The ClassiX® system with ObjectStore 6.x uses several schema databases assigned to the DLLs. The specification Schema is ignored.
The location of the schema databases can be controlled with the environment variable OS_SCHEMA_PATH (see schema databases).

CheckIllegalPointers
Only for ObjectStore 5.x: For the program development phase the ObjectStore feature of the same name is activated. At the end of each transaction, ObjectStore checks whether objects to be stored in the database may refer to objects in transient memory. This keyword is parameterless.

From ObjectStore 6.x this feature is always active.

DLLs
The DLLs containing the code of the model classes must be specified here. Parameter is a list of the names of the DLLs without the extension .DLL.

If the name of a DLL contains characters which are not alphanumeric, or special characters or umlauts, the name must be placed in quotation marks.

DLLs("dll1-version2_EXT_", dll2_EXT_, "dll3-version3_EXT_")

Always enter only the DLLs actually required by the customer! (Is Instant-Web or the ELSTER interface actually needed?)
This way ClassiX starts faster and a higher value for OS_AS_SIZE can be specified (see Address Space)

Help
Only for the OS/2 version of the ClassiX® system: Here it was specified where the ClassiX® system can find the InstantView® documentation (which you are currently reading) as online help. In the path name the characters ### are replaced by the country code according to the current language (compare instruction Language).

WinEditor
With these keywords the command to call an editor is specified (see instruction EditSource).

Icon(Path)
With this parameter any application icon for ClassiX can be set. The path must lead to an .ico file. The environment variable CX_ROOTDIR may be used here.

The command changes the icon from:

• All windows in the upper left corner
• The taskbar icon for the application
• The Tray

Example: Icon("CX_ROOTDIR\\\icons\\\classix.ico")

SystemDB
The path to a database containing the information from CLASSIX.INI stored in the database is to be entered here.
This database may contain the complete metadata or only part of it (which may also be empty), but it must exist. Otherwise the system will abort with an error message.