Kommen wir also nur zur der Struktur, zu dem Aufbau des "Super-Arrays" welches wir in den Textdateien ablegen wollen. Die Struktur sollte gut durchdacht und vor allem erweiterungsfähig sein. Neben den Datensätzen müssen auch sogenannte Meta-Daten, also Daten, welche von der FlatBox zur Verwaltung benötigt werden mit abgespeichert werden.
Aus diesem Grund haben wir das Array erst mal in "Meta" und "Data" Informationen unterteilt:
Array
(
[meta] => Array
(
)
[data] => Array
(
)
)
Machen wir uns nun erst mal um [data] Gedanken - hier sollen die einzelnen Datensätze abgelegt werden - doch wie soll das nun genau geschehen?
[data] => Array
(
[1] => Array
(
[name] => dennis
[lastupdate] => 20050718152213.644197
[created] => 1121721733
)
[2] => Array
(
[name] => Tom
[lastupdate] => 20050718152214.004041
[created] => 1121721733
)
)
Bei [data] handelt es sich um ein indiziertes Array, also ein Array mit numerischen Indexen. Jedes Array in [data] entspricht einem Datensatz, dabei entspricht der Index dieses Arrays der ID des Datensatzes. Die Nummerierung für die ID's beginnt bei 1 - nicht bei 0! Im obigen Fall haben wir also zwei Datensätze, einen mit der ID 1, sowie einen mit der ID 2.
In beiden Datensätzen existiert ein Feld [name], welches für dieses Beispiel frei gewählt wurde und mit dem Programm in keinster Weise zusammen hängt. Es können auch noch beliebig viele weitere Werte mitgespeichert werden.
Die Felder [lastupdate] und [created] sind jedoch keine vom Programmierer frei gewählten Felder. Es handelt sich hierbei um Felder, welche die FlatBox zur Verwaltung der Datensätze benötigt und selbstständig anlegt. Ein Manipulieren oder anderweitiges Verwenden dieser Felder ist ebenfalls nicht möglich.
In [created] wird ein UNIX Timestamp gespeichert, der den Zeitpunkt angibt, zu dem der Datensatz angelegt wurde (per flat_rec_insert()). Das andere Feld [lastupdate] hingegen enthält einen Spezial Timestamp, welcher den Zeitpunkt angibt, zu dem der Datensatz das letzte mal mit flat_rec_update() bearbeitet wurde - ist der Datensatz noch nie geupdated worden, so bezeichnet dieser Timestamp den gleichen Zeitpunkt, wie der Timestamp in [created]. Um mehr über den Sinn der [lastupdate] Timestamps zu erfahren, lesen Sie bitte den Abschnitt Multi-User Fähigkeit.
Kommen wir jetzt zu [meta] - welche Informationen brauchen wir im Programmablauf alle?
[meta] => Array
(
[created] => 1121721733
[lastupdate] => 20050718152214.004041
[lastid] => 2
[amount] => 2
[filetype] => flatfile
)
Als erstes bräuchten wir einen Timestamp, wann der vorliegende FlatFile überhaupt erzeugt wurde. Dafür reicht ein einfacher UNIX Timestamp, der auf die Sekunde genau ist.
Zweitens bräuchten wir noch die Information, wann der FlatFile das letzte mal geändert wurde. Hier reicht ein UNIX Timestamp schon nicht mehr - er ist zu ungenau. Deshalb kommt hier unser Spezial Timestamp zum Einsatz, der wesentlich genauer ist.
In lastid speichern wir die ID, die dem zuletzt eingefügten Datensatz gegeben wurde, die wird benötigt, damit immer fortlaufend neue ID's für die Datensätze vergeben werden können. In amout speichern wir schließlich noch die Anzahl der vorhandenen Datensätze. Im obigen Beispiel mag dies unsinnig aussehen, da lastid und amout identisch sind - ist es aber nicht, schließlich können ja Datensätze gelöscht werden, wodurch amout zwar sinken, lastid jedoch gleich bleiben würde.
Letztendlich gibt es noch filetype - dies ist bis jetzt immer flatfile, diese Information wird zum aktuellen Zeitpunkt noch nicht weiter verwendet. Für die Zukunft ist gedacht, über diesen Parameter eine Unterscheidung zwischen einem aktuellen FlatFile, sowie einem Archiv FlatFile vornehmen zu können. In einem Archiv FlatFile bräuchte man z.B. auch die Information [lastid] nicht mehr, denn in einen Archiv FlatFile sollen ja keine Datensätze mit flat_rec_insert() eingefügt werden können - lediglich flat_rec_copy() kann das Verschieben von Datensätzen aus aktuellen FlatFiles in Archiv FlatFiles vornehmen.
Dieser Punkt ist nicht zu Verwechseln mit "Gleichzeitigem Zugriff von mehreren Usern vorbeugen". Bei dem erwähnten Punkt ging es darum, dem zeitgleichen Zugriff von mehreren Usern auf die Speicher-Dateien vorzubeugen und somit die Dateien vor Zerstörung zu schützen. In diesem Punkt hier soll es vielmehr darum gehen, was passiert, wenn mehrere User gleichzeitig Datensätze bearbeiten bzw. bearbeiten wollen.
Man stelle sich z.B. folgendes vor: User A hat in dem Datensatz mit der ID 5 etwas gefunden, was ihm nicht gefällt - er beschließt diesen Datensatz zu ändern. Während User A noch fleißig am Schreiben ist, ruft User B eine Übersicht aller Datensätze auf und entdeckt ebenfalls die "Unschönheit" in dem Datensatz mit der ID 5. Nun ist User A mit seinem Editieren fertig, der aktualisierte Datensatz ist abgespeichert. Jetzt will User B den Datensatz Nr. 5 löschen, dabei weiß er nicht, dass dieser gerade von User A schon bearbeitet wurde und gar nicht mehr gelöscht werden muss.
Und schon wäre der Konflikt da - User B würde eine Version von dem Datensatz mit der ID 5 löschen, die er selber noch gar nicht gesehen hat, da er die Übersicht über alle Datensätze seit dem Speichern von User A nicht mehr in seinem Browser aktualisiert hat.
Es wären noch beliebig viele weitere solche Situationen denkbar, die sich aber alle im Kern her ähnlich wären und darauf hinaus liefen, dass man irgendetwas mit einer Version eines Datensatzes macht, die man überhaupt nicht kennt, die man noch gar nicht gesehen hat.
Wir brauchen also irgendeine Möglichkeit, festzustellen, welche Version eines Datensatzes die betroffene Person gesehen hat und müssen diese Information weitergeben, damit die entsprechenden Funktionen der FlatBox, die Operationen an einem Datensatz vornehmen feststellen können, ob die von der Person gesehen Version des Datensatzes immer noch aktuell ist.
Was in der Theorie sehr kompliziert klingen mag, ist im praktischen Gebrauch eigentlich einfach zu verstehen. Wie bereits im Abschnitt "Struktur des Arrays" erwähnt, speichern wir in jedem Datensatz noch einen lastupdate - Timestamp mit. Hierbei handelt es sich um eine Information, die den Zeitpunkt festhält, zu dem das letzte Mal eine Operation an dem Datensatz vorgenommen wurde.
Der erwähnte Timestamp wird in jedem Datensatz von der Funktion flat_rec_select() mit ausgegeben und muss den Funktionen flat_rec_update() und flat_rec_delete() übergeben werden, damit diese das Aktualisieren bzw. das Löschen vornehmen. Bekommen diese Funktionen nicht den Timestamp, der auch im FlatFile selber steht, so brechen sie alle Operationen an dem Datensatz ab.
Alle Funktionen der FlatBox liefern einen einheitlichen Errorcode zurück, die Codenummer sagt genauere Informationen über den Ablauf der Funktion aus.
Wichtig: Beachten Sie, dass der Code für "ohne Fehler abgelaufen" 0 ist und somit folgendes nicht zum gewünschten Ergebnis führen würde:
<?php if(flatboxfunction()) { //Weiterer Ablauf do_this(); } ?>
Wenn ein Fehler aufgetreten ist wird je nach dem, ob die Konstanten PRINT_NOTICES, PRINT_WARNINGS und PRINT_FAILES auf true gesetzt sind oder nicht die Fehlerbeschreibung zu der Fehlernummer direkt ausgegeben oder nicht. Die Rückgabe der Funktionen ist auf jeden Fall immer der Errorcode.
Folgende Errorcodes gibt es bis jetzt:
Weitere Errorcodes können jederzeit eingeführt werden.
© 2005, Dennis Riehle, Thomas Schmieder