CLASSIX.INI

Initialisierungsdatei CLASSIX.INI

• Beschreibung
• Syntax des Initialisierungs-Files
• Syntax der Sektion 'Metainfo'
• Syntax der Sektion 'Dictionary'
• Sektion 'Metainfo'
• Sektion 'Dictionary'

Beschreibung

Die beim Start des ClassiX^®-Systems benötigte Information wird in einem Initialisierungsfile bereitgestellt. Dem Starter-Programm cx_osr.EXE kann mit Flag -I ein beliebiger Pfad vorgegeben werden. Fehlt eine explizite Pfadangabe, wird die Initialisierungsdatei entsprechend der Vorgaben durch die Umgebungsvariablen CX_SYSTEM und CX_ROOTDIR gesucht:

1. in allen mit CX_SYSTEM angegebenen Directories
2. im Directory CX_ROOTDIR\System

Mittels #include-Anweisungen kann die Initialisierungs-Datei aus mehreren Files zusammengesetzt werden (und die Suche nach den includierten Files wird ebenfalls durch  CX_SYSTEM bzw. CX_ROOTDIR gesteuert).

Der aus einem oder mehreren Files bestehende Text, der beim Start des Systems alle wesentlichen Parameter zur Initialisierung bereitstellt, wird innerhalb dieser Dokumentation kurz mit CLASSIX.INI bezeichnet.

Viele der in CLASSIX.INI möglichen Angaben können auch in der Datenbank gespeichert sein. CLASSIX.INI muss dann auf diejenige (physische) Datenbank verweisen, welche die System-Information enthält. Diese System-Datenbank darf auch eine der physischen Datenbanken sein, in der die Objekte gespeichert werden. Die Information aus der Datenbank kann durch weitere Angaben in CLASSIX.INI ergänzt werden. Überdefinitionen sind nicht möglich; darüber hinaus ist die Verteilung der Information zwischen System-Datenbank und CLASSIX.INI-File beliebig. Man kann auch auf eine Datenbank verweisen, die überhaupt keine Systeminformation enthält. Aber die Datenbank muss existieren. 
Ohne diese Einschränkung würde das ClassiX^®-System bei einer fehlerhaften Pfadangabe zur System-Datenbank stillschweigend mit dem auf die Angaben aus CLASSIX.INI beschränkten Parametersatz starten.

Hinweis: Wenn alle Datenbanken neu erzeugt werden sollen, muss die gesamte System-Information in CLASSIX.INI beschrieben sein und es darf keinen Verweis auf eine System-Datenbank geben, oder es muss der Parameter /G verwendet werden (siehe SystemDB). 

CLASSIX.INI ist in zwei Sektionen unterteilt. Der Beginn einer Sektion wird mit den Schlüsselwörtern MetaInfo bzw. Dictionary gekennzeichnet. Die folgende Tabelle führt auf, welche Angaben in CLASSIX.INI möglich sind. Ein Stern in Spalte DB besagt, dass die entsprechende Information auch in der Datenbank gespeichert sein kann.

Verwandte Themen

• Syntax der Einträge in CLASSIX.INI
• Erläuterungen zu Sektion Dictionary
• Erläuterungen zu Sektion MetaInfo
• Meta-Daten in der Datenbank speichern
• Start des ClassiX^®-Systems

Syntax des Initialisierungs-Files

Die Syntax des Files CLASSIX.INI wird vollständig in Backus-Naur-Notation beschrieben, wobei Terminalsymbole rot gekennzeichnet sind:

InitializationData ::= [DictionarySection] MetaInfoSection

Die Syntax der Sektion 'MetaInfo'

MetaInfoSection ::= MetaInfo MetaInfoEntries

MetaInfoEntries ::= MetaInfoEntry | MetaInfoEntries MetaInfoEntry

MetaInfoEntry ::= DLLs | SchemaDB | IndexCopy | CheckIllegalPointers | DatabaseList | AutoLayer | SystemDB | ClassEntry | FileEntry | StorageEntry | SegmentEntry | Help | WinEditor

IndexCopy ::= IndexCopy(FLAT) | IndexCopy(DEEP)

SchemaDB ::= Schema(schemaDBLocation)

DLLs ::= DLLs(DLLList)

DLLList ::= dllName | DLLList , dllName

dllName ::= identifier

DatabaseList ::= Database | DatabaseList Database

Database ::= Database(integerNumber, identifier)

AutoLayer ::= AutoLayer(integerNumber, physicalDatabaseList)

physicalDatabaseList ::= physicalDatabase | physicalDatabaseList, physicalDatabase

SystemDB ::= SystemDB(identifier)

Help ::= Help(fileName)

WinEditor ::= WinEditor(editorIdentifier)

ClassEntry ::= Class(className, classID [, [fileName] [, [baseClassName]]] [[,] [entryPointIndex]]]][,] [Cluster(integerNumber)[,]]Docu(integerNumber))

className, baseClassName ::= identifier

classID ::= integerNumber

entryPointIndex ::= integerNumber | zugriffsAusdruck

FileEntry ::= File(fileName, storageNames)

fileName ::= name

storageNames ::= identifer | identifier storageNames | ...

StorageEntry ::= Storage(storageName, physicalDataBase, [Segment], rootEPList, CSeg(collSegList), Garbage(rootEntryPoint, segmentName))

physicalDataBase ::= DB(integerNumber)

storageName ::= name

Segment ::= Seg(segmentList) | segmentID

segmentList ::= segmentID | segmentList, segmentID

segmentID ::= segmentName

SegmentEntry ::= Segment(segmentName, physicalDataBase, segmentParameter)

segmentParameter ::= EXTERN | AUTO | DEFAULT

rootEPList ::= rootEntryPoint | rootEPList, rootEntryPoint

rootEntryPoint ::= EP(rootEntryPointName[(collectionType)])

rootEntryPointName ::= name

collectionType ::= BAG | SET | LIST | ARRAY

collSegList ::= segmentName | collSegList, segmentName

segmentName ::= name

name ::= identifier | string

Die Syntax der Sektion 'Dictionary'

DictionarySection ::= [Dictionary] [Size] DictionaryEntryList

Size ::= Size(integerNumber)

DictionaryEntryList ::= DictionaryEntry | DictionaryEntryList DictionaryEntry

DictionaryEntry ::= SpecifierDescriptor | SlotDescriptor | DataMemberDescriptor | IndexDescriptor | RetrieveDescriptor

SpecifierDescriptor ::= Specifier(specifierName, integerNumber)

specifierName ::= name

SlotDescriptor ::= Slot(slotName, [semanticDescription,] integerNumber, typeName [, transformationTable | className])

slotName ::= name

DataMemberDescriptor ::= Member(fieldName, [semanticDescription,] typeName [, transformationTable])

fieldName ::= zugriffsAusdruck

IndexDescriptor ::= Index(slotID, integerNumber)

slotID ::= identifier[.identifier]

RetrieveDescriptor ::= Retrieve(zugriffsAusdruckListe, integerNumber) [returns(typeName)]

zugriffsAusdruckListe ::= zugriffsAusdruck | zugriffsAusdruckListe, zugriffsAusdruck

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 | STRING | CXB_STRING | CXB_MULTIPLE_STRING | className

transformationTable ::= "fileName[~sectionName]" | "identifier()"

sectionName ::= identifier

Zum Schluss noch einige der bisher benutzten elementaren Metavariablen:

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

Es fehlt die formale Definition für 'string' und 'fileName', deren Gestalt als bekannt vorausgesetzt werden darf.

Sektion 'MetaInfo'

Dieser Abschnitt des Initialisierungs-Files teilt dem Objektmanager mit, welche Klassen es gibt, wie die Datenbank logisch aufgeteilt wird und an welcher Stelle innerhalb der Datenbank die Objekte einer Klasse gespeichert werden sollen (weitere Erläuterungen):

Die Beschreibung, wo und wie Objekte einer Klasse zu speichern sind, wird als File zusammengefasst. Verschiedene Klassen können die gleiche File-Information benutzen. Ein File verweist auf Storages. Der Objektmanager führt einen Index i und lässt für alle Files jeweils nur den i-ten Storage sichtbar werden, wodurch die Datenbank logisch in voneinander unabhängige Bereiche - Layer - aufgeteilt wird. Wenn man in Layer i arbeitet, besteht kein Zugriff auf die Daten in Layer k. Layer unterteilen die Menge aller gespeicherten Objekte in disjunkte Teilmengen, d.h. ein Objekt kann nur einem Layer angehören.

Storages definieren Parameter, die direkt mit der gewählten Speicherungsform zusammenhängen. Im folgenden werden Storages für die Datenbank ObjectStore beschrieben. ClassiX^® kann mit beliebig vielen physischen Datenbanken arbeiten - daher gehört diese Angabe zum Storage. Für das Verständnis der anderen Parameter hilft ein Blick auf die innere Struktur der ObjectStore-Datenbank:

Die Datenbank ist in Segmente unterteilt. Folglich muss festgelegt werden, in welchem Segment die Objekte gespeichert werden. Um Daten in einer ObjectStore-Datenbank wiederzufinden, müssen sie direkt oder indirekt mit einem Root-Entry-Point verbunden sein. Im Storage werden mit einem Root-Entry-Point verbundene Collections definiert. Diese Collections fassen die Objekte einer Klasse zusammen. Die Menge aller Objekte einer Klasse kann auf verschiedene Collections verteilt sein. Die damit entstehenden Teilmengen heißen bei ClassiX^® Domains. Ein Objekt darf mehreren Domains angehören, d.h. die Teilmengen sind nicht notwendigerweise disjunkt.

Ein Objekt darf auch Element der Collection(s) seiner Basisklasse(n) sein. Ebenso wie Objekte befinden sich auch die Collections in einem bestimmten Segment der Datenbank. Da innerhalb einer Collection häufig nach Objekten gesucht wird, ist damit zu rechnen, dass die Verteilung der Objekte und Collections auf die Segmente die Performance einer Anwendung mitbestimmt.

Der Objektmanager löscht ein Objekt nur logisch. Deshalb gehört zum Storage die Angabe, wo logisch gelöschte Objekte aufbewahrt werden (Segment, Collection).

Wie oben erwähnt, können Objekte auf verschiedene physische Datenbanken verteilt werden. ObjectStore erlaubt Relationen zwischen Objekten in unterschiedlichen Datenbanken. Dieses Feature muss jedoch explizit aktiviert werden, indem für das betroffene Segment EXTERN angegeben wird.

Für jede Collection kann der Typ bestimmt werden. Ohne explizite Angabe wird eine Set erzeugt.

Nach dem Schlüsselwort Schema wird angegeben, wo sich die ObjectStore-Schema-Datenbank befindet.

Besonders wenn neue Klassen entwickelt werden, können durch Programmfehler illegale Pointer in die Datenbank geschrieben werden. ObjectStore kann dies feststellen - jedoch auf Kosten der Performance. Mit dem Schlüsselwort CheckIllegalPointer wird dieser Modus aktiviert.

Die Angaben zu den Klassen, Files und Storages werden üblicherweise in eine eigene Datei ausgelagert (classix.odb) welche dann per include-Anweisung in der Datei classix.ini eingefügt wird. Im Folgenden wird der oben Beschriebene Aufbau der Angaben zu dem Speichertort von Objekten an einem Beispiel beschrieben.

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"))

In der ersten Zeile wird für die Klasse CX_SPAN_DATE die eindeutige Nummer 31022 festgelegt und dem File date zugeordnet. Außerdem wird hier angegeben, dass die Klasse von CX_DATE abgeleitet ist und eine Zuordnung zur Dokumentation hergestellt.
In der Zweiten Zeile wird dann das File date definiert und der Storage für jedes Layer angegeben. In diesem Fall wird für das Layer 0 empty angegeben, da die Speicherung im Layer 1 erfolgen soll.
In der letzten Zeile wird schließlich der für Layer 1 angegebene Storage definiert, zunächst der Name, dann folgt die Datenbank. Als nächstes wird der Name des Segments angegeben, in welchem die Objekte gespeichert werden. Mit der Angabe EP wird der Name des Root-Entry-Point festgelegt, über den die Collection mit allen Objekten dieser Klasse erreicht wird. Die Angabe CSeg legt den Namen des Segments fest, in welchem eben diese Collection abgelegt wird. Als letztes wird schließlich angegeben, in welchem Segment gelöschte Objekte aus diesem Storage archiviert werden.

Sektion 'Dictionary'

In diesem Abschnitt werden Slots beschrieben. Ein Slot wird durch seinen Namen und eine ganze Zahl identifiziert. Außerdem muss der Datentyp bekannt sein.

Auch 'gewöhnliche' Datenmember können hier beschrieben werden. Dies ist für Datenfelder der Typen ENUMSHORT und ENUMCHAR von Interesse, da hier auf eine Transformationstabelle verwiesen wird. InstantView^® benutzt diese Tabelle automatisch, wenn der Wert eines solchen Datenfeldes in eine Zeichenkette konvertiert werden muss oder umgekehrt. Das Windowobjekt Enumeration zeigt die Bezeichner aus der Tabelle in einer Combobox.