Lade...
 

AddIndex

AddIndex

Achtung!
Veraltet! Indexmanager stellt Funktionen für die Indexverwaltung zur Verfügung

AddIndex(CX_xxxxx), AddIndex(CX_xxxxx, k)

Parameter: Bezeichner einer Klasse, Nummer einer Domain (Default ist k = 0)

Stack
Stack Position Beschreibung
Stack(In) Top ]
  Top-1 Parameter
    . . .
  Top-n [
Stack(Out)   -

Eine RootEP-Collection der als Parameter angegebenen Klasse erhält einen Index. Parameter k wählt die Collection aus: Innerhalb des aktuellen Layers (siehe SetLayer) ist es die k-te der im ersten Parameter angegebenen Klasse. Mit SetDomain gesetzte Einstellungen sind hier wirkungslos (Hinweis ...).

Auf dem Stack werden folgende Parameter erwartet:

Typ Bedeutung  
Zeichenkette der Indexpfad muss angegeben werden
ganze Zahl Optionen optional, Standardannahme = ORDERED + COPY_KEY
OBJECTS_PER_TXN n fordert Indexaufbau in mehreren Transaktionen, pro Transaktion werden n Objekte verarbeitet optional, nur sinnvoll um Address-Space-Überlauf zu vermeiden

Optionen werden durch die Konstanten ORDERED, NO_DUPLICATES, POINT_TO_KEY, COPY_KEY beschrieben (mehrere Konstanten mit + oder | zusammenfassen). Ein Index kann mit DropIndex wieder entfernt werden.
AddIndex erzeugt einen Eintrag im Indexmanager (ein Objekt CX_INDEX_DESCRIPTOR).

Collections existieren auch als Element eines Objekts. Ein Index für solch eine Collection wird mit

AddIndex(CX_xxxxxx, zugriffsAusdruck)

aufgebaut, wobei folgende Parameter angegeben werden:

Typ Bedeutung  
Objekt Objekt, von dem aus die Collection erreicht wird muss angegeben werden
Zeichenkette der Indexpfad muss angegeben werden
ganze Zahl Optionen optional, Standardannahme = ORDERED + COPY_KEY
OBJECTS_PER_TXN n fordert Indexaufbau in mehreren Transaktionen, pro Transaktion werden n Objekte verarbeitet optional, nur sinnvoll um Address-Space-Überlauf zu vermeiden

Als Indexpfad kann ein Ausdruck gebildet werden, der

  1. den von ObjectStore vorgegeben Möglichkeiten entspricht, d.h. es können feste Datenfelder und ...
  2. im Datenbankschema bekannte Query-Funktionen aufruft.
  3. auf dynamische Datenfelder verweist. Dynamische Datenfelder, mit denen ein Index aufgebaut werden soll müssen vorher in CLASSIX.INI mit Anweisung Index angemeldet werden. 
  4. Mit der Pseudofunktion Retrieve können ein oder mehrere InstantView®-Zugriffsausdrücke als Parameter übergeben werden.
  5. Der Datentyp POINTER kann nicht indiziert werden, weder als festes Datenfeld noch als Slot.

Für 1. und 3. wird der Index automatisch nachgeführt, wenn sich der Wert eines Objektattributes ändert, von dem die Stellung dieses Objekts innerhalb des Index abhängt. Für die "festen" Datenfelder ist im DDI angegeben, ob für dieses Feld ein Index aufgebaut werden kann. Die Einschränkung dient der Performanceverbesserung: Der Overhead für die Indexaktualisierung wird bei Datenfeldern, für die niemals ein Index aufgebaut wird, zu vermieden.
Außerdem kann für ein Datenfeld im DDI angegeben werden, welche Query-Funktionen von seinem Wert abhängen. Indizes mit diesen Query-Funktionen werden dann automatisch nachgeführt (Fall 2.).
Für einen Index nach 3. gibt es kein automatisches Update! Hier muss die Aktualisierung des Index (eventuell auch mehrerer Indizes (!) explizit angestoßen werden (siehe Retrieve).

Für Indizes über einen Integer- oder Enum-Slot gilt eine Besonderheit: Wenn der Slot nicht vorhanden ist, wird ein Wert von 0 angenommen. Die 0 kann also entweder den Wert "0" darstellen, oder sie bedeutet: Slot nicht vorhanden.

- Beispiele -

InstantView®