Brickhistory
Beim Speichern eines Bricks wird immer eine neue Revision des Bricks in er Datenbank angelegt, damit entsteht die sogenannte Brickhistory.
Wenn die Tabelle dann zu groß wird, kann man in der IDE unter Werkzeuge Toolbricks den Brick DLETools_DeleteOldBrickRevisions starten.
Es folgt eine Dialogabfrage nach dem Datum, bis zu dem die History gelöscht werden soll. Bei manchen Daten gibt es Beschränkungen mit der Transaktionsgröße, in diesem Fall kann nach n Sätzen ein Commit angefordert werden. Aktuelle Bricks können damit nie gelöscht werden.
Die DLE verwendet einen internen Cache Mechanismus für Bricks. Einmal geladene Bricks werden in dem durch das Sessionparameter BrickDirectory angegebenen Verzeichnis lokal zwischengespeichert (Default ist temp/gen).
Um diesen Cache zu leeren, kann in dem Sessionparameter RemoveBrickDays die Zeit in Tagen angegeben werden, nachdem Bricks aus dem Cache gelöscht werden sollen.
Diese Reorganisation wird automatisch bei dem ersten Start eines Bricks aus einer neuen Session aufgerufen.
Um die Reorganisation manuell aufzurufen, steht die Methode purgeFilesCache(float days) in der API zur Verfügung. Als Parameter erhält sie die Zeit in Tagen. Alle Dateien, die älter als diese Anzahl von Tagen sind, werden gelöscht. Wird -1 angegeben, wird das Sessionparameter RemoveBrickDays verwendet.
Eine weitere Reorganisierungsfunktion, die aus der API aus aufgerufen werden kann, betrifft die Historisierung von Brickrevisionen. Bei jedem speichern eines Bricks aus einem Editor, wird eine neue Revision angelegt und die alte historisiert. Dies ist nicht zu verwechseln mit Brickversionen, die im Editor manuell mit einem Gültigkeitsdatum angelegt werden.
Die Methode purgeBrickRevisions(float days) kann dazu verwendet werden, alte Revisionen zu löschen. Als Parameter erhält sie die Zeit in Tagen. Alle Revisionen, die älter als diese Anzahl von Tagen sind, werden gelöscht. Wird -1 angegeben, wird das Sessionparameter RemoveBrickCodeDays verwendet.