The initialization file provides all required information to start ClassiX®. The flag -I, makes it possible to define any path for the starting program cx_osr.EXE. In case an explicit path specification is missing, the initialization file gets searched:
The initialization file can be put together out of several files via #include statements, (the search for the included files is also controlled with CX_SYSTEM / CX_ROOTDIR).
The text, here indicated as CLASSIX.INI, consists of one or more files and provides all relevant initialization parameters at system start.
Many possible specifications in CLASSIX.INI can be saved in the
database. CLASSIX.INI has to refer to the
specific (physical) database, which contains system information. This system
database can also be one of the physical databases storing the objects.
The database information can be complemented by further specifications in CLASSIX.INI.
Overdefinition is not possible; moreover, information interchange between
system database and the CLASSIX.INI- file is arbitrary. It is also possible to refer
to a database, which contains no system information at all, as long as the database exists.
Without these constraints, a faulty path specification to the system database
would make ClassiX® start with the parameter
set, which is limited to the CLASSIX.INI
specifications.
Information: Regenerating all databases, the entire system information needs to be described in CLASSIX.INI. There must be no reference to a system database, since otherwise the parameter /G (see SystemDB) has to be applied.
CLASSIX.INI is divided into two sections. The section start is indicated by the keywords MetaInfo / Dictionary. The following table lists possible specifications in CLASSIX.INI. A star in column DB indicates, that the according information can be also saved in the database.
| Information | in section | DB |
|---|---|---|
| model classes | MetaInfo | * |
| model class DLLs | MetaInfo | |
| how to save the objects of this class in the database (meta files, storages, segments, clustering) | MetaInfo | * |
| all generateable slots | Dictionary | * |
| characteristics of 'normal' data members | Dictionary | * |
| character set (ISO 8859-1 or code page 850) | MetaInfo | * |
| schema database (only for ObjectStore 5.x) | MetaInfo | |
| check illegal pointer modus (only for ObjectStore 5.x) | MetaInfo | |
| DLLs for external functions | MetaInfo | |
| path for system online-help | MetaInfo | |
| editor access for InstanView® source code | MetaInfo |
The file syntax of CLASSIX.INI is completely described in the Backus Naur Notation. Workstation symbols are highlighted in red:
InitializationData ::= DictionarySection MetaInfoSection | MetaInfoSection DictionarySection | MetaInfoSection
MetaInfoSection ::= MetaInfo | SchemaDB MetaInfo | CheckIllegalPointers SchemaDB MetaInfo | SchemaDB CheckIllegalPointers MetaInfo
MetaInfo ::= ClassDescription FileDescription StorageDescription
ClassDescription ::= ClassEntry | ClassDescription ClassEntry
ClassEntry ::= Class(className, classID, fileName) | Class(className, classID, fileName, baseClassName)
className ::= identifier
baseClassName ::= identifier
FileDescription ::= FileEntry | FileDescription FileEntry
FileEntry ::= File(fileName, storageList)
storageList ::= storageDescription | storageList, storageDescription
fileName ::= name
StorageDescription ::= StorageEntry | StorageDescription StorageEntry
StorageEntry ::= Storage(storageName, physicalDataBase, Segment, EP(rootEPList), CSeg(collSegList), Garbage(rootEntryPoint, segmentName))
storageName ::= name
Segment ::= segmentName | segmentName(EXTERN)
rootEPList ::= rootEntryPoint | rootEPList, rootEntryPoint
rootEntryPoint ::= rootEntryPointName | rootEntryPointName(collectionType)
rootEntryPointName ::= name
collectionType ::= BAG | SET | LIST | ARRAY
collSegList ::= segmentName | collSegList, segmentName
segmentName ::= name
name ::= identifier | string
DictionarySection ::= DictionaryEntry | DictionarySection DictionaryEntry
DictionaryEntry ::= SlotDescriptor | DataMemberDescriptor
SlotDescriptor ::= Slot(slotName, semanticDescription, integerNumber, typeName)
DataMemberDescriptor ::= Member(fieldName, semanticDescription, typeName [, transformationTable])
semanticDescription ::= multipleStringConstant
multipleStringConstant ::= T(listOfStrings)
listOfStrings ::= string | listOfStrings, string
typeName ::= INTEGER | SHORT | CHAR | ENUMSHORT | ENUMCHAR | POINTER | COLL | REL_11 | REL_1M | REL_M1 | REL_MN | CXB_STRING | CXB_MULTIPLE_STRING | className
transformationTable ::= fileName[~sectionName]
sectionName ::= identifier
And finally some of the fundamental meta variables which have been used so far:
identifier ::= letter | identifier alnum_char
letter ::= A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | _
digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
alnum_char ::= letter | digit
integerNumber ::= digit | integerNumber digit
The formal definition for 'string' and 'file name' is missing, since it is assumed that they are.
This part of the initialization file informs the object manager of existent classes, of how to logically divide the database and where exactly in the database to save object classes:
A file abstracts, where and how to save objects of the same class. Different classes can use the same file information. A file refers to storages. The object manager maintains an index i and only lets the i-th storage become visible for the according file. This logically divides the database into independent divisions (layers). Working in layer i, it is not possible to access data in layer k. Layers divide the amount of all saved objects into disjunctive subsets - one object can only belong to one layer.
Storages define parameters, which are directly connected to the selected storage type. The following describes storages for the database ObjectStore. ClassiX® works with any amount of physical databases - therefore, this specification belongs to the storage definition. To help understand the other parameters, please have a look at the internal ObjectStore database structure:
The database is divided into segments. Therefore, it is necessary to define which segment stores the objects. To retrieve data in an ObjectStore database, they have to be connected to a root entry point - either directly or indirectly. Collections that are connected to a root entry point, are defined in the storage. These collections integrate objects of a class. The class objects can be spread across different collections. The emerging subsets in ClassiX® are called domains. An object can belong to several domains, meaning the subsets are not necessarily disjunctive.
An object can also be a collection element of its basic class(es). The collections are located in a specific database segment, just like the objects. Since objects are often searched insde a collection, collection- and object distribution across the segments can be expected to codetermine application performance.
The object manager deletes an object only logically. Therefore, the specification of where logically deleted objects are stored (segment, collection), belongs to the storage.
As mentioned above, objects can be distributed across different physical databases. ObjectStore allows for object relations in different databases. This feature has to be activated explicitly though, by indicating EXTERN for the respective segment.
The type can be defined for each collection. The set is generated without explicit specification.
After the keyword scheme, the ObjectStore database location is indicated.
Bugs can cause illegal pointers in the database, especially, when developing new classes. ObjectStore can detect these - but only with performance suffering at the same time. The keyword CheckIllegalPointer activates this modus.
Class-, file-, and storage specifications are generally swapped in a personal file (classix.odb) and pasted into the file classix.ini via include statement. The following shows a design sample for specifications of an object storage location.
Class(CX_SPAN_DATE, 31022, date, CX_DATE, 0, Docu(142))
File(date, empty, date)
Storage(date, DB(1), "dateS", EP("dateL0"), CSeg("cs.basic"), Garbage("geps1", "gcs1"))
The first line defines the explicit number 31022 for the class CX_SPAN_DATE and assigns it to the file date. Furthermore, it indicates the class as a derivation from CX_DATE and establishes an assignment to the documentation. The second line defines the file date and indicates the storage for each layer. In this case, it indicates that layer 0 is empty, since the storage is supposed to be in layer 1. The last line finally, defines the storage for layer 1 - first the name and then the database. Then follows the specification of the segment which stores the objects. The specification EP defines the root entry point name leading to the collection with all objects of this class. The specification CSeg defines the name for the segment with this collection. Finally, it specifies the segment archiving deleted objects from this storage.
This paragraph will teach you about slots. A slot is identified by a name and an integer. Furthermore, the data type needs to be known.
"Common" data members can also be described here. This is relevant for ENUMSHORT and ENUMCHAR data field types, as it is referred to as a transformation table. InstantView® uses this table automatically to convert the value of such a data field into a string, or vice versa. The window object Enumeration displays the identifier from the table in a combobox.