Opened by Kean at 2011-05-09 09:16
User since
2011-03-19
3199 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
2011-03-19
3199 Artikel
BenutzerIn
Hi, danke für Feedback.
eval ist klar: die Anweisung(en) kommen in einen eval{} Block und danach wird $@ abgefragt.
Die Philosophie von RaiseError ist so zu verstehen: Fehlermeldungen werden in den Status einer Exception "gehoben". Ohne Fehlerbehandlung mit eval{} würde _jede Fehlermeldung (naja, fast jede...) dazu führen, dass das Script stirbt. Das mag auf den ersten Blick aufwändig erscheinen, macht jedoch am Ende die Fehlerbehandlung in Sachen DBI sehr handhabungssicher.
Zu Deiner Frage. Mein Code ist ein Teil der new() in einer eigenen Klasse, die eine DB-Anbindung realisiert. In der Methode ist $self eine Instanz dieser Klasse, $self ist eine Referenz auf einen Hash.
Die Anweisung
$self->{SCALAR} = $sth->execute;
fügt dem Objekt eine Eigenschaft hinzu, in diesem Fall den Return-Value von execute().
Die anderen Anweisungen
fügen ebenfalle Attribute dem Objekt hinzu, {CB} ist eine Referenz auf eine Callbackfunktion (für die Ausgabe des Abfrageergebnis) und {STH} ist das Statement-Handle.
Der Aufruf der Klasse sieht dann so aus:
Edit: SQL.pm ist eine einfache Klasse zum realisieren des DB-Management über den Browser, hier gibt es ein Eigabefeld (textarea) wo die Query reinkommt, das Ergebnis wird als Plain/text dann im Browser ausgegeben. Bei einem Fehler im Statement/Query kommt die Response in text/html wunderschön formatiert ;)
Falls noch Fragen, poste einfach.
PS/edit: Tie-Klassen ermöglichen eine Trennung der Datenhaltungs-Schicht von der Anwendungs-Schicht.
In Lezterer wird ganz normal mit Perl-Variablen (scalar, hash, array) operiert.
Das hat den Vorteil, dass die Datenhaltung von der Anwendung abstahiert ist, ändert sich die Datenhaltung, ist im Code der Anwendung keine Änderung erforderlich. Im Code der Anwendung stehen auch keine SQL-Statements. Es werden (Ausnahme Callbackfunktionen) auch keine Methoden aufgerufen, sondern einfach nur in Variablen geschrieben oder aus Variablen gelesen. Insert/Select usw. läuft versteckt im Hintergrund.
Änderungen/Anpassungen in der Datenhaltung sind nur noch in der Tie-Klasse vorzunehmen. Ein 'alter table' ist dann schnell mal gemacht ohne den Code umschreiben zu müssen. Oder die Datenhaltung wird von mySQL aud Postgresql umgestellt. Oder die Datenhaltung wird von DB auf Datei umgestellt... die Tie-Klasse ist austauschbar.
Last edited: 2011-05-11 10:16:47 +0200 (CEST)
eval ist klar: die Anweisung(en) kommen in einen eval{} Block und danach wird $@ abgefragt.
Die Philosophie von RaiseError ist so zu verstehen: Fehlermeldungen werden in den Status einer Exception "gehoben". Ohne Fehlerbehandlung mit eval{} würde _jede Fehlermeldung (naja, fast jede...) dazu führen, dass das Script stirbt. Das mag auf den ersten Blick aufwändig erscheinen, macht jedoch am Ende die Fehlerbehandlung in Sachen DBI sehr handhabungssicher.
Zu Deiner Frage. Mein Code ist ein Teil der new() in einer eigenen Klasse, die eine DB-Anbindung realisiert. In der Methode ist $self eine Instanz dieser Klasse, $self ist eine Referenz auf einen Hash.
Die Anweisung
$self->{SCALAR} = $sth->execute;
fügt dem Objekt eine Eigenschaft hinzu, in diesem Fall den Return-Value von execute().
Die anderen Anweisungen
fügen ebenfalle Attribute dem Objekt hinzu, {CB} ist eine Referenz auf eine Callbackfunktion (für die Ausgabe des Abfrageergebnis) und {STH} ist das Statement-Handle.
Der Aufruf der Klasse sieht dann so aus:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10
if(tie my $status, 'SQL', {query => $sql-zeugs, CB => \&callback}){ # Ok, wir können $status abfragen und die Callbackfunktion rufen tied($status)->cb_array; # Method in Class 'SQL' # in cb_array{} wird vermittels {STH} über das Resultat iteriert # und jede Zeile als Array-Referenz an die Callback-Funktion {CB} gegeben } else{ # Nein, es gab einen Fehler, wir fragen $@ }
Edit: SQL.pm ist eine einfache Klasse zum realisieren des DB-Management über den Browser, hier gibt es ein Eigabefeld (textarea) wo die Query reinkommt, das Ergebnis wird als Plain/text dann im Browser ausgegeben. Bei einem Fehler im Statement/Query kommt die Response in text/html wunderschön formatiert ;)
Falls noch Fragen, poste einfach.
PS/edit: Tie-Klassen ermöglichen eine Trennung der Datenhaltungs-Schicht von der Anwendungs-Schicht.
In Lezterer wird ganz normal mit Perl-Variablen (scalar, hash, array) operiert.
Das hat den Vorteil, dass die Datenhaltung von der Anwendung abstahiert ist, ändert sich die Datenhaltung, ist im Code der Anwendung keine Änderung erforderlich. Im Code der Anwendung stehen auch keine SQL-Statements. Es werden (Ausnahme Callbackfunktionen) auch keine Methoden aufgerufen, sondern einfach nur in Variablen geschrieben oder aus Variablen gelesen. Insert/Select usw. läuft versteckt im Hintergrund.
Änderungen/Anpassungen in der Datenhaltung sind nur noch in der Tie-Klasse vorzunehmen. Ein 'alter table' ist dann schnell mal gemacht ohne den Code umschreiben zu müssen. Oder die Datenhaltung wird von mySQL aud Postgresql umgestellt. Oder die Datenhaltung wird von DB auf Datei umgestellt... die Tie-Klasse ist austauschbar.
Last edited: 2011-05-11 10:16:47 +0200 (CEST)