File Locking, Fehlerbehandlung

[Tom]

Hello,

Noch eine "Philosophie Frage", wie du sie nennst:

Sollen wir am Anfang des Sriptes einmal festlegen $time_u und $time_s gleich und das den entsprechenden Funktionen mitübermitteln oder sollen wir das in jeder in Frage kommenden Funktion einzeln festellen lassen?

MMn nein, sonder nur am Anfang jeder Funktion, denn die könnte sich auch gegensetig aufrufen und Konkurrenz machen (Rekursion, Schachtelung). meine Frage war nun nur, wollen wir das innerhalb einer Funktion bei jedem Datensatz neu bestimmen oder nur am Anfang der Funktion. Die Funktion selber macht sich ja keine Konkurrenz, sodass man diese kleine Ungenauigkeit (< 0,09sec) zugunsten der Perfomance in kauf nehmen könnte.

Der Pfad zur Datei wird in $filename definiert;
Den würde ich dann auch $filepath nennen, wenn schon.
$filename ist dann nur der Basename des Files.

OK, ändere ich um und schicke dir die Hauptdatei (gerade geschickt) noch mal neu zu.

Ich auch...

Unser Mega Array heißt $_file, in gepacketer Fomr $_file_packed;

Datensätze heißen $_record

Solange Sie noch nicht in $_file drinnen sind.

Ja, genau. $_file ist das entpackte Pendant zum File, $_record ist nur ein Datensatz innerhalb von $_file['data']

Wen  ein Datensatz zum Update angemeldet wird, der noch nicht odr nicht mehr in der Datei enthalten war, welchen Meinstamp ['lastupdate'] soll der dann erhalten? Den, den er bereits hatte (aus der anderen Datei, aus der er stammt) oder einen frischen, da er ja eben angefasst wurde...

Ich finde, wenn ein Datensatz geändert wird, also upgedatet wird, muss das ['created'] immer gleich bleiben, in jedem Fall. Das ['lastupdate'] hingegen, mit den Millisekunden, sollte jedoch immer erneuert werden.

OK, da er beim Übertragen von A nach B nicht geändert wird, bleibt der Timestamp gleich. Ich habe das nun so gemacht:

Wenn der Satz mit flat_update() in ein File eingetragen wird, in dem er noch nicht enthalten war (also quasi ein Insert oder Re-Insert bzw. eben Übertragung von A nach B), dann behält er den mitgebrachten Meinestamp, es sei denn er bringt keinen mit, dann bekommt er den aktuellen. ['created'] ist unantastbar ;-))

Ein Datensatz, der von aktuell.dat -> archiv.dat geschoben wird, wird in keinster Weise geändert. Ein Datensatz kann _nicht_ von einer Archivs Datei wieder nach aktuell.dat gelangen!

Doch, bei der Datenrücksicherung! Und da darf ja der LastUpdate auch nicht geändert werden. Das war der passende Hinweis. Danke.

Hm, soll es denn überhaupt die Möglichkeit geben, einen multi-flat_insert() zu machen? Ich meine, der Administrator kann doch immer nur eine neue News schreiben und da kommt es doch nicht zu einem mehrfachen insert!

Aber nicht beim Übertragen von 737 selektierten Datensätzen von A nach B. da sind es eben 737. Warum sollen wir dann das File 737 mal öffnen uns schließen, wenn da  mit einem Mal auch geht?

Mach Dich mal frei von dem Adminstrator. Den gibt es noch gar nicht. Den gibt es eigentlich sowiso nicht. Es gibt nur User des Systems. Die haben allerdings alle andere Rechte auf Daten und Objekte (also auch auf sich selbst). dminstrator ist nur ein Synonym für eine  User mit besonders vielen Rechten.

Anders ist das bei Update, da soll es ja eine mehrfach Auswahl geben, um mehrere Datensätze auf einmal zu ändern, und dann auf Abspeichern zu klicken (hab ich dich da so richtig verstanden?).

Ja.

Allerdings ist hier die Frage mit dem alle-den-gleichen-timestamp-oder-nicht auch schon von vorneherein eigentlich klar, da wir ja gesagt haben, ['created'] wird bei Update _nie_ geändert, und ['lastupdate'] wird ja nicht veröffentlicht. Also kann man da frei wählen, ob man für ['lastupdate'] mehrfach das gleiche Datum verwenden will. Kommt auf das Script drauf an, ob es mit mehreren gleichen Daten zurecht kommt.

Es geht eben schneller, wenn man nicht x-mal microtime() und date() und substr() aufrufen muss.

Ich möchte dich und auch mich *g* erinnern, dass wir die Funktionen flat_rec_insert() und flat_rec_select() genannt haben.

Oh ja, also auch das noch korrigieren.

Liebe Grüße aus http://www.braunschweig.de

Tom