Perlartikel auf rolfrost.de (Perl: Community, Bücher, Neuigkeiten)

[thread]16574[/thread]

Perlartikel auf rolfrost.de

Leser: 34

Articles: hide open all | hide show old branches

+11 replies
rosti

2011-07-31 08:37

User since
2011-03-19
3492 Artikel
BenutzerIn

Quote
konrolllesen lohnt sich wieder :)

Probelesen, jawoll. Gut gemacht hast Du es, keine Frage. In meiner Eigenschaft als langjähriger Autor habe ich jetzt auch wieder damit begonnen, mir einzelne Themenbereiche für kleinere Artikel vorzunehmen, Übersicht hier: http://rolfrost.de/map/article

Meine beiden letzten Artikel handeln vom grundsätzlichen Aufbau eines CGI-Scripts und der Andere befasst sich mit dem Klassenentwurf für DB-Anbindung. In Letzterem gibt es auch einen Abschnitt zur sinnvollen Verwendung einer Callbackfunktion und ein Abschnitt zum Thema Pagination.

http://rolfrost.de/map/article/dbi

Splitted from PerlTutorial im Freien Magazin msg #150866
Last edited: 2011-07-31 16:39:30 +0200 (CEST)
- +6 replies
- pq
  
  2011-07-31 12:11
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  2011-07-31T06:37:29 rosti
  der Andere befasst sich mit dem Klassenentwurf für DB-Anbindung. In Letzterem gibt es auch einen Abschnitt zur sinnvollen Verwendung einer Callbackfunktion und ein Abschnitt zum Thema Pagination.
  
  http://rolfrost.de/map/article/dbi
  
  es mag ein beispiel sein, wie man callbacks einsetzt, aber ausser zum lernen würde ich das nicht empfehlen. nichtmal zum lernen finde ich alles gut, z.b. dass die diversen fehler bei den connects und executes unterdrückt werden, ist sicher nicht hilfreich bei der fehlersuche.
  
  ich empfehle, sich für abstraktion von SQL SQL::Abstract bzw. DBIx::Class anzuschauen.
  gerade die doku von SQL::Abstract erläutert in vielen beispielen, was es kann und damit auch, was man in einem selbst gestrickten modul alles implementieren müsste. denn sonst kommt man schnell an die grenzen und ist eher gefrustet, dass man für jede neue art eines selects oder updates den code umständlich erweitern muss.
  
  ich würde die beiden module auch unbedingt in dem artikel erwähnen und kurz daran aufzeigen, warum der code im artikel nur ein beispiel sein sollte. sonst bekommt man eventuell den eindruck, du würdest die module nicht kennen.
  
  statt des callbacks hätte ich hier übrigens einen iterator verwendet, ähnlich wie DBI und DBIx::Class es machen.
  Last edited: 2011-07-31 12:13:18 +0200 (CEST)
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +5 replies
  - rosti
    
    2011-07-31 12:46
    
    User since
    2011-03-19
    3492 Artikel
    BenutzerIn
    
    Quote
    nichtmal zum lernen finde ich alles gut, z.b. dass die diversen fehler bei den connects und executes unterdrückt werden, ist sicher nicht hilfreich bei der fehlersuche.
    
    Welche diversen Fehler meinst Du? Und wo werden die in meiner Klasse unterdrückt? (edit) Bitte werde da mal etwas konkreter. Ich möchte auch was Lernen ;)
    
    Noch ein Edit: Zur Fehlerbehandlung setze ich RaiseError und teste auf Exception mit eval{}. Du kannst in der Dokumentation selbst nachlesen, dass diese Vorgehensweise die einzige Möglichkeit ist, vom DB-Layer eine aussagekräftige Fehlermeldung zu erhalten, für den Fall, dass bereits der Connect fehlschlägt.
    
    Meine Klassen sichern diesen Fehlerfall einwandfrei ab. Darüber hinaus werden mögliche Fehlerfälle auch beim execute auf Exception getestet.
    Last edited: 2011-07-31 13:32:57 +0200 (CEST)
    - +4 replies
    - pq
      
      2011-07-31 13:58
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      RaisError ist eine gute Sache. Sie ermöglicht dem Programmierer, das Programm oder einen Abschnitt einfach sterben zu lassen. Ein fehlgeschlagenes connect oder prepare ist wohl in jedem Fall ein Grund für einen Abbruch, bei execute zumindest in den meisten Fällen.
      Mit deinem eval zwingst du jedoch den Anwender wieder, bei jedem Aufruf ein "or die" anzuhängen. Zudem finde ich es unschön, auf $@ zuzugreifen, wenn das eval eine subroutinen-ebene tiefer liegt.
      Mit dem Modul nimmst du dem User den Segen der RaiseError-Option weg.
      
      Die meisten DBI-aufrufe sollten, wie schon gesagt, sowieso zu einem Abbruch führen, lediglich bei einzelnen Statements möchte man eventuell den Fehler selber abfangen und darauf reagieren, dann packt man im skript selber ein eval drumherum.
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - +3 replies
      - rosti
        
        2011-07-31 14:18
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Zu allgemein Deine Antwort;)
        
        Wenn Du schon nicht konkreter werden möchtest, Du ich es:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
        
        sub new{ my $class = shift; my %cfg = ( user => '', pass => '', port => 3306, host => 'localhost', base => '', @_ ); # das Objekt mit dem DB-Handle und dem Statement-Handle my $self = bless{ DBH => undef, STH => undef, }, $class; # Prepared Statement my $q = q(SELECT name FROM unicode WHERE cpd = ?); my $dsn = "DBI:mysql:database=$cfg{base};host=$cfg{host};port=$cfg{port}"; eval{ $self->{DBH} = DBI->connect_cached( $dsn, $cfg{user}, $cfg{pass}, { RaiseError => 1, PrintError => 0, } ); $self->{STH} = $self->{DBH}->prepare_cached($q); }; return $@ ? undef : $self; }
        
        Setze zum Testen RaiseError auf 0 und fahre den mysqld runter. Der Fehler tritt beim Erstellen des Statement-Handles auf. Du bekommst keinen DBH, erfährst jedoch nicht die Ursache, auch nicht aus anderen DBI-Fehler-Variablen, aus dem einfachen Grund, weil das Handle nicht existiert.
        
        Das ist das, worauf in der DBI-Doku hingewiesen wird. Und genau das habe ich in meinem Tutorial auch geschrieben. Ebenfalls in der DBI-Doku wird empfohlen, zur Fehlerbehandlung das Exception-Modell zu verwenden. Ob Du das persönlich als 'unschön' bezeichnest, ist Deine Sache.
        
        Deine lapidare Bemerkung wie
        Quote
        nichtmal zum lernen finde ich alles gut,
        betrachte ich somit auch als persönliche Ansichtsache Deinerseits, verbunden mit einem untauglichen Versuch, mein Tutorial in ein schlechtes Licht zu rücken.
        
        Und ja: Wenn ich was schreibe, ist das auch ausführlich getestet. Über Feeback freue ich mich immer, das sollte jedoch schon etwas konkreter sein.
        
        Schönen Sonntag,
        Grüße an Alle,
        Rolf
        
        +2 replies
        
        pq
        
        2011-07-31 14:26
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2011-07-31T12:18:24 rosti
        verbunden mit einem untauglichen Versuch, mein Tutorial in ein schlechtes Licht zu rücken.
        
        du hast ein tutorial ins netz gestellt, und ich habe es kritisiert und meine kritik auf nachfrage konkret genug erläutert. wenn du mir unterstellst, dass ich versuche, das tutorial in ein schlechtes licht zu rücken, ist wohl eh jede weitere diskussion sinnlos.
        ich rate davon ab, fertig. wenn du das persönlich nimmst, ist das dein problem.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        rosti
        
        2011-07-31 17:41
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Deine Aussage, dass in der in meinem Tutorial vorgestellten Klasse
        
        Quote
        dass die diversen fehler bei den connects und executes unterdrückt werden, ist sicher nicht hilfreich bei der fehlersuche.
        
        hast Du immer noch nicht mit konkreten Beispielen belegt. Das ist keine Kritik sondern Polemik.
        
        Für Kritik bin ich weiterhin offen ;)
        
        --Rolf
- +4 replies
- topeg
  
  2011-08-01 06:07
  User since
  2006-07-10
  2611 Artikel
  BenutzerIn
  Ich würde das Modul von DBI ableiten Dann kann man gleich "$dbi->errstr()" etc. nutzen.
  alternativ würde ich selber eine Error-Methode erstellen
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
  
  sub error { my $self=shift; my $error=''; $error=$self->{_error} if($self->{_error}) $self->{_error}=''; return $error; } sub _set_error { my $self=shift; my $error=shift // ''; $self->{_error}=$error; }
  
  zusammen mit RaiseError => 0 und
  
  Code (perl): (dl )
  
  1 2 3 4 5
  
  unless($self->{DBH}->do(...)) { $self->_set_error($self->{DBH}->errorstr()); return undef; }
  
  Ich mag es nicht sonderlich globale Variablen zu nutzen. Hier mag es nützlich und auch nicht schädlich sein, doch sollte man es sich gar nicht erst angewöhnen und vermeiden wo man es kann.
  
  Es ist zwar nett alles in eval zu packen, aber hier ist es unnötig, da DBI sauber arbeitet und kein die macht wenn man es nicht wünscht.
  
  Ich würde mit den Error sogar soweit gehen und einen Handler dafür erlauben:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
  
  sub set_error_callback { my $self=shift; my $handler=shift // sub{}; return 0 unless(ref($error) eq 'CODE'); $self->{_error_handler}=$handler; return 1; } sub _set_error { my $self=shift; my $error=shift // ''; $self->{_error}=$error; $self->{_error_handler}->($self,$error) $self->{_error_handler}; }
  
  Das kann dann direkt in die Basisklasse.
  Last edited: 2011-08-01 06:08:45 +0200 (CEST)
  - +3 replies
  - rosti
    
    2011-08-01 09:18
    
    User since
    2011-03-19
    3492 Artikel
    BenutzerIn
    
    Hi Topeg,
    
    danke Dir!
    
    Quote
    Es ist zwar nett alles in eval zu packen, aber hier ist es unnötig, da DBI sauber arbeitet und kein die macht wenn man es nicht wünscht.
    
    Es gibt _immer_ mehrere Möglichkeiten und $dbi->errstr greift auch auf eine globale Veriable. $dbi->errstr funktioniert überdies nur, wenn das Handle erstellt werden konnte.
    
    Von daher leitet sich die Empfehlung ab, RaiseError bereits beim connect zu setzen, da es die Einzige Möglichkeit ist, zu erfahren, warum der connect schief geht. Das hat dann eben zur Konsequenz, dass jeder Fehler eine Exception wirft, es sei denn, RaiseError wird nach dem connect wieder auf Null gesetzt (wäre zu prüfen).
    
    Dein Tipp mit der eigenen Fehlerfunktion ist auf jeden Fall eine feine Sache und empfehlenswert, die meisten meiner Module haben eine Solche. In meinem Artikel
    
    http://rolfrost.de/map/article/cgi/fin
    
    habe ich beschrieben, was mit einer eigenen Fehlerfunktion möglich ist.
    
    --Rosti
    
    Edit: Artikel ergänzt um einen Abschnitt "Fehlerbehandlung" mit oder ohne RaiseError. Ich persönlich werde $@ weiterhin bevorzugen, das wird im Gegensatz zu $DBI::errstr NICHT überschrieben, sofern auch nur eines der im eval{}-Block notierten Statements fehlschlägt.
    
    Wenn RaiseError gesetzt ist, werden die im eval-Block abgesetzten Statements erst wirksam in der DB, wenn _alle_ Statements korrekt sind. Ergo: Mögliche Fehler sind gut aufzuspüren, zügige Arbeitsweise ;)
    Last edited: 2011-08-01 11:42:53 +0200 (CEST)
    - +2 replies
    - Gast wer
      
      2011-08-01 11:46
      
      Code (perl): (dl )
      
      1 2
      
      my $dbi=DBI->connect(''); die DBI->errstr() unless $dbi;
      
      Last edited: 2011-08-01 11:56:27 +0200 (CEST)
      - rosti
        
        2011-08-01 18:35
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Die Art der Fehlerbehandlung ist stets abhängig von der Aufgabenstellung. Wenn es dazu reicht, festzustellen, ob ein Handle erstellt werden kontte oder nicht und egal warum, falls nicht, ist das auch in Ordnung ;-)

View all threads created 2011-07-31 16:39.