anpera.net

Hallo,

ich versuche mich derzeit an meiner ersten OOP Arbeit.
Dazu möchte ich gerne die Logs von jeder Gilde speichern. Errorlogs, Buildlog, etc. pp.!
Also hab ich mir gedacht, lass es über die setting Tabelle speichern. Hab das value Feld auf TEXT umgestellt usw..
Ich kann das Array auch ein und auslesen & verändern.

Allerdings hab ich eine Frage bezüglich des Speichercodes der Log's. Ich wollte wissen was ihr anders machen würdet.

Hier mal die Funktion:

$this->bbcode_second_pass_code('', 'public function guildLog($input,$section,$guild,$guildname,$date) {

if (db_num_rows(db_query('SELECT setting FROM settings WHERE setting="guildLog"'))==1) {

$log = unserialize(getsetting('guildLog',null));
$value = end($log);
$last_key = key($log);

$log[$guild][$section][($last_key+1)]['msg'] = $input;
$log[$guild][$section][($last_key+1)]['general']['id'] = $guild;
$log[$guild][$section][($last_key+1)]['general']['name'] = $guildname;
$log[$guild][$section][($last_key+1)]['general']['date'] = $date;

savesetting('guildLog',serialize($log));

} else {

$log = array();
$log[$guild][$section][0]['msg'] = $input;
$log[$guild][$section][0]['general']['id'] = $guild;
$log[$guild][$section][0]['general']['name'] = $guildname;
$log[$guild][$section][0]['general']['date'] = $date;

savesetting('guildLog',serialize($log));

}

}')

_________________
Never change a running system. Bullshit!

Ich würde dafür lieber eine eigene Tabelle anlegen, ähnlich wie de debuglog Tabelle, in der ich nur die GildenId, Datum und den Text speicher. Den soweit ich weiß wird die settingstabelle immer geladen und auf dauer kann dein gildenlog endlos lang werden was nicht so gut für die performance wäre...

Und in einer eigenen Tabelle hast du ne bessere übersicht und besseres zugriffsmöglichkeiten zu den logs.

EDIT: ist das die einzige methode in der class? Wenn ja würde es ne einfache funktion auch tun. Da diese einzige Methode nicht den Sinn von OOP erfüllt, wobei es natürlich trotzdem funktionieren würde.

Die Frage ist hier wirklich, wie viel mitgeloggt werden soll?

Weil wenn das ein Wenig mehr wird, dann sollte das schon in eine Eigene Tabelle ausgelagert werden, oder in die LogTabelle wenn es so etwas im Std gibt?

Und ich denke es sollte eigentlich ausreichend sein, wenn du dir ID und die Message nimmst soeiwe das Datum, weil der Name, sollte ja aus der ID schon ermittelt werden koennen also wenn unbedingt notwendig durch einen weiteren Select ermittelt werden, aber ich denke Notwendig in erster Instance ist das ganze nicht

Evtl auch noch ein kleiner Gedanke, eine Art "Loglevel" einzusetzen.

Also das er nicht alles mitloggt sondern eben nur nach bestimmten faellen, bzw auch optional alles.

ganz meine rede xD, wobei ich schon alles logen würde... Wobei nja ok... je nachdem welchen zweck es erfüllen soll. Unter umständen wär es auch sinnvoll nicht alles zu logen, das stimmt schon.

Aber ne eigene Tabelle sollte schon sein, da egal ob viel oder wenig gelogt werden soll, würde es zumindest auf dauer endlos lang werden...

@Chaos sry, das ich deines nochma wiederholt habe, hatte meinen Beitrag geschrieben und vergessen abzuschicken und somit deinen erst gelesen nachdem ich meinen geschrieben hatte, wollte dich also nicht wiederholen.

Wie man sieht wird in dem Code nirgendwo die Klasse an sich definiert, daher konnte man schon von alleine schlussfolgern, dass es nicht die einzige Funktion in der Klasse ist.

& es wird generell nicht alles mitgeloggt. Sondern eher wichtige Dinge.

Wie z.B:

$this->bbcode_second_pass_code('', '
if (is_array(unserialize($row['treasury']))) {
$this->treasury = $row['treasury'];
} else {
$this->treasury = array();
$this->guildLog('Das Array Treasury konnte scheinbar nicht als Array geladen werden.','error',$this->id,$this->name,date('d.m.y | H:i:s'));
}')

Noch etwas zu den Logs: Die Logs würden eh alle 2-3 Tage automatisch vom System gelöscht werden. Daher würden es nicht Unmengen von Code geben. Aber nun gut.



Das war allerdings meine Frage &' nicht was die Performance angeht. ^^

_________________
Never change a running system. Bullshit!

Ich werde, wie gewünscht, sagen was ich an dem Snippet anders gemacht hätte.
Dies bedeutet nicht, dass ich die log Funktion so als sinnvoll erachte!



Eine Klassen-Funktion, die nicht auf $this zurückgreift sollte man in PHP 5.x als static deklarieren, damit du wenn du sie zB mal statisch aufrufen willst nicht an performance verlierst oder unter 5.3 sogar den Dienst verweigert. Zwar sind statische Aufrufe von der Geschwindigkeit minimal langsamer, aber ihre allgemeinen Vorteile überwiegen in diesem Fall.

$this->bbcode_second_pass_code('', 'if (db_num_rows(db_query('SELECT setting FROM settings WHERE setting="guildLog"'))==1) {')

Hier fängt es dann erstmal an warum überhaupt dieses SQL Statement?

Wenn du unbedingt vorher eine Query machen willst dann ist ein COUNT sauberer auch wenn vllt auf dem ersten Blick mehr arbeit.

Aber hier ist erst gar keine Query von nöten.

hier reicht:

$this->bbcode_second_pass_code('', 'if (is_array($log = unserialize(getsetting('guildLog',null)))) {')

$this->bbcode_second_pass_code('', '
$value = end($log);
$last_key = key($log);
$log[$guild][$section][($last_key+1)]['msg'] = $input;
')

Das kannst du dir auch sparen, da php keys selber verwaltet.

Fazit code sollte eigentlich so aussehen:




Und die eleganteste Lösung:

Eine Log-Methode gehört prinzipiell zu einem Objekt der Klasse Gilde, womit schonmal die Parameter "Gildenname" und "Gilde" wegfallen. Hier ist schonmal der erste Fehler. Für Einträge in Fremdlogs könnte man eine zusätzliche, statische Funktion definieren, die Einträge in fremde Logs über die GildenID erlaubt.

Aber die settings-Tabelle missbrauchen? Fehler Nummer zwei. Wie bereits erwähnt ist eine Tabelle nach dem Vorbild des debuglogs bei weitem besser - optimal sogar eine Datei (mit dem richtigen Zugriffsfunktionen), wenn die Einträge nicht zu frequentiert eingetragen werden, ganz nach dem Unix-Vorbild.

Bei Text-Dateien kann sich sogar eine zusätzliche Log-Verwaltungs-Klasse um das rotieren der Dateien kümmern und das löschen zu alter Dateien - und vielleicht das komprimieren älterer logs.