nicht angemeldet
Hello again,
etwas ausführlicher,
elsif($aktion eq 'sql'){
>
> Och nö! Laß mich raten: Diese `elsif ($action eq 'irgendwas')`{:.language-perl} stapelst Du vom Fundament bis über das Dach. Sagt Dir der Begriff "Dispatch Table" etwas? [LMGTFY](http://www.google.com/search?&q=dispatch+table+site%3Aperlmonks.org).
Ja, natürlich, damit habe ich auch schon gearbeitet, der Code schrumpft zusammen, aber ist später u.U. schwerer nachzuvollziehen, da sind Kontrollstrukturen manchmal besser.
> > ~~~perl
> > read(STDIN, my $st, $ENV{CONTENT_LENGTH});
> >
Bastelst Du Dir Deine eigene CGI-Schnittstelle?
Nein. Ich mache nur den Body frei von Control-Elementen, die der UA schickt. Es ist eine Client-Server-Anwendung zum Datenbank-Management über HTTP. Der body kann verschiedene Inhalte haben, auch Binaries oder reine SQL-Statements. Was am Server zu tun ist, wird im Custom-Request-Header übergeben (Control) und der Body wird Bytegenau aus STDIN gelesen. Da STDIN ein Handle ist, können mit read() auch Sequenzen gelesen werden, also nicht über {CONTENT_LENGTH}, sondern auch mal so:
read(STDIN, my $record, $record_len);
my $aref = $dbo->{DBH}->selectall_arrayref($st); if($DBI::errstr){ print "\nFehler: $DBI::errstr\n"; }
>
> Kaputt.
>
> Warum nutzt Du nicht $dbo->{'DBH'}->errstr()? Die globalen Variablen ..
Das ist eine Altlast, hier bin ich gerade dabei, die DB-Zugriffe in Subklassen mit eigenen Namespaces zu organisieren, da wird $dbo->{DBH} nicht mehr verwendet, sondern es werden nur noch Methoden der Subklasse aufgerufen, das betrifft auch die Fehlerbehandlung.
> Warum nutzt Du nicht [RaiseError](http://search.cpan.org/~timb/DBI-1.616/DBI.pm#RaiseError), wie in der DBI-Doku empfohlen?
Coming soon ;)
> Warum müllst Du den Speicer mit einem Ergebnis voll, dass Du ohnehin zeilenweise benutzen willst?
Es sind kleine Datenmengen, da darf ich auch maln komplettes Array in den RAM legen.
> Nutze eine while-Schleife in Kombination mit [fetchrow_arrayref() alias fetch()](http://search.cpan.org/~timb/DBI-1.616/DBI.pm#fetchrow_arrayref) oder meinetwegen [fetchrow_array()](http://search.cpan.org/~timb/DBI-1.616/DBI.pm#fetchrow_array). So hast Du immer nur eine Zeile im Speicher.
> Für maximale Geschwindigkeit und minimales Umkopieren kannst Du fetch() in Kombination mit [bind_col()](http://search.cpan.org/~timb/DBI-1.616/DBI.pm#bind_col) nutzen, auf die Art schreibt DBI gleich in die Variable, mit der Du (typischerweise innerhalb der while-Schleife) weiterarbeiten willst.
Wenn ein DB-Abfrage-Ergebnis zum Browser geht, hat die Anzahl der Zeilen \_immer einen endlichen Wert, das darf ich als Array in den Speicher legen. Mit fetchrow\_ zu arbeiten, hieße: Ausgabe der Daten mit der Darstellung zu vermischen, aber ich trenne das lieber. Liegt das Ergebnis als Array im Speicher, wird das zur Darstellung nicht kopiert, sondern eine Referenz übergeben, dann erst gehts zur Darstellung (HTML).
Anders ist es beim Management, da gehen schonmal Binaries mit einigen MB vom Server raus auf STDOUT und fetchrow\_ wäre serverseitig angebracht. Clientseitig wäre es natürlich ungeschickt, eine solche HTTP-Response erst als String UA-seitig in ein temp. Handle zu schreiben, naheliegender ist es doch, gleich die Response aus dem Socket zu lesen.
Hotti
Struppi