Explanations for the section MetaInfo

Sektion 'MetaInfo'
Required for each class:

• an entry to describe the class (ClassEntry)
• eventually further specifications for persistent storage (FileEntry, StorageEntry)
• DLL specification, which contains the code of the new class (ModelDLLs)

The following image shows the interplay between CLASSIX.INI information, the function New() and the ObjectManager, if it generates an instance of a class A:

Class
generates an object CX_META_CLASS, which contains information about a class. Parameters are:

• class name
• an integer, which represents this class in the ClassiX^® System
• the name of a meta file (see further below)
• basic class name
• bitpattern to control pasting in REP collections
• cluster(n) - claims, that every persistent object of the class is saved in a separate cluster. The cluster size n has no meaning in ObjectStore 6.0 or later versions.
• Docu(n) refers to the CyberEnterprise^® documentation file of this class.

Basic classes which will never generate an object are often entered to completely specify the inheritance path. The meta file specification can be dropped for this class. Derivation of all classes from CX_CLASS is known in the ClassiX^® System a priori, even, if CX_CLASS has not been entered in CLASSIX.INI.

At this stage,  the term 'class' is used with an extended meaning: The term class in C++ or Java, can be pictured as an object classification, which leads to continued division. With the keyword

PseudoClass
it is possible to break down objects of one C++ class into sub-classes. Parameters are the same as in Class.

File
generates an object of the class CX_META_FILE. As the name indicates, this object provides information about how the objects are saved in the database. Main content is a vector, which refers to n storages. This organization reflects the logical database fragmentation into layers. Parameters are:

• a (specified) name
• a list of storage names

After names for the last storage specification can follow the ellipse ... . This notation prevents from constantly repeating the same parameter, in case the same storage specifications shall apply for all (now following) layers:

The last storage definition of the file statement is repeated as often as defined by the file statement with the most  storages.

File(fName₁, stg₀, stg₁, stg₂, stg₃)

File(fName₂, stg_a, ...)

File(fName₁, stg₀, stg₁, stg₂, stg₃)

File(fName₂, stg_a, stg_a, stg_a, stg_a)

The parameter STOP is only relevant in connection with the statement AutoLayer.

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

• a unique name
• the physical database
• the segment(s) that store objects
• a list of Root-EntryPoint-Collections names
• a list of segments, which store the root entry point collections
• name tuple of a collection with logically deleted objects (database recycle bin) and the segment for this collection
  

It is referred to the physical database with

• path specification
• the name of an environment variable, which contains the current path to the database at the start
• DB(k), a reference to the statement Database(..., k)  

There are two segment specifications: object- and slave segment. The existence / absence of the object segment defines the clustering strategy, when generating an object with the statement CreatePersObject:

Slave objects do not control, where and how they are saved in the database. At first, a "lazy creator" develops, Instead of the real object. The first object that builds a relation to the "lazy creator" defines the location in the database. Here, the slave segment specification becomes important:

Abstract:

In a storage specification for a class X,

Segment
This statement is required, if further segment characteristics (not just the name) shall be specified.
First parameter is the segment name and after, the following specifications are possible:

Database
describes a physical database and assigns an integer k to it. With DB(k), it is possible to refer in the storage statements to this database. The name is the complete or relative path to the database file, or the name of an environment variable with a value, which refers to the database file at the system start.

Information: It is not permitted to have different storages refer to the same physical database in a different way, e.g. via different environment variables or different, but equivalent path specifications. Starting the ClassiX^® System discovers such ambiguities.

AutoLayer
Whenever the objective is, to describe a logical database, which 

• is consist of many, basically identical layers
• and which assigns an own physical database to each layer,

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

IndexCopy(FLAT | DEEP)
This parameter controls database indices mith the option COPY_KEY. Default option is FLAT.

Information: Changing from FLAT to DEEP or vice versa is only possible after deleting all database indices. After, the desired modus is entered in the .ini file and all indices are rebuilt.

Scheme
Only for ObjectStore 5.x: Here, the scheme database path is specified by ObjectStore. Just like in 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 scheme databases, which are assigned to the DLLs. The specification scheme is ignored. The scheme database location can be controlled with the envirmonment variable OS_SCHEMA_PATH (see scheme databases).

CheckIllegalPointers
Only for ObjectStore 5.x: The ObjectStore feature is activated for this progam development phase. At the end of each transaction, ObjectStore checks, if the objects, which are going to be saved in the database, refer to objects in the transient storage. This key word has no parameter.

For ObjectStore 6.x and later versions, this feature is always active.

DLLs
The DLLs that contain the model class code, are to be specified here. Parameter is a name list of the DLLs without the extension .DLL.

FormulaCppDLLs
Objects of the class CX_FORMULA can call external functions - functions, that are not part of the ClassiX^® Systems. With this, it is possible to swap calculation rules, which have been reasonably programmed in C++.

Damit können spezielle Berechnungsvorschriften, die sinnvollerweise in C++ programmiert sind, ausgelagert werden. As a parameter, there is a list of DLL names without the extension .DLL.

Help
Only for the OS/2 version of the ClassiX^® Systems: It has been specified here, where the ClassiX^® System finds the  InstantView^® documentation (which you are currently reading) as online help. in the path name, the characters ### are replaced according to the current language (compare statement Language).

OS2Editor   WinEditor
These keywords specify the for OS/2 / Windows the command to call an editor (see statement EditSource).

ISO8859_1
This parameter specifies, if the ISO 8859-1character set (Microsoft Windows character set) is used. For the platforms Windows 95 and Windows NT, this is the default option, while the assumption ISO8859_1(OFF) applies for OS/2. In case a database shall be used on both operating systems, ISO8859_1(OFF) has to be set for the Windows platforms.

SystemDB
Here, the path to a database, which contains the database information from CLASSIX.INI (see function SaveMetaInfo of the object manager).
This database can contain the complete meta data or only a part of it (which can also be empty), but in any case, it has to be existent. Otherwise, the system start gets cancelled with a problem report.