[DBIx::Class] prefetch, ->next() auf related tables (gelöst) (Datenbanken und Verzeichnisdienste)

[thread]18722[/thread]

[DBIx::Class] prefetch, ->next() auf related tables [gelöst]

Tags: perl5 DBIx::Class Ähnliche Threads

Leser: 11

Articles: hide open all | hide show old branches

+7 replies
Britzel

2013-11-04 16:20
User since
2012-10-02
20 Artikel
BenutzerIn
Moin.

Es existiert eine Haupttabelle 'Artikel', dazu eine 1:n table 'art2att', die Relation heisst 'art2atts'.

Mit DBIx::Class hole ich mir ein ResultSet aus der Table 'artikel':
Code: (dl )

1 2 3 4 5 6 7 8 9 10

my $rs = $schema->resultset('Artikel')->search( { 'art2atts.id_at' => $aid, def_attgroup => { IN => \@gids } }, { select => ['artnum', 'artname', 'text', ], prefetch => ['art2atts'], order_by => 'artnum', });
So weit, so gut, funktioniert.

Nun will ich auf das Resultset zugreifen. Das Problem besteht beim dereferenzieren eines Feldes der related table 'art2atts'.

Man beachte: '$row->art2atts' ist ein Objekt vom Typ 'DBIx::Class::ResultSet'.

Wenn ich das so mache:
Code: (dl )

1 2 3 4 5 6 7 8 9 10

while ( my $row = $rs->next ) { # Welchen Artikel haben wir denn hier? say "Artikel: ",$row->artnum," Name: ",$row->artname; # Welche Attribute hat dieser Artikel? while ( my $inner_row = $row->art2atts->next() ) { say "Attribut-Id: ",$inner_row->id; } }
dann wird der erste Artikel endlos oft ausgegeben, d.h. $row->art2atts->next() iteriert nicht.

Wenn ich hingegegen dieses innere ResulSet zunächst einer Variablen zuweise (siehe Zeile 6):
Code: (dl )

1 2 3 4 5 6 7 8 9 10

while ( my $row = $rs->next ) { # Welchen Artikel haben wir denn hier? say "Artikel: ",$row->artnum," Name: ",$row->artname; # Welche Attribute hat dieser Artikel? my $irs = $row->art2atts; while ( my $inner_row = $irs->next() ) { say "Attribut-Id: ",$inner_row->id; } }
dann geht das problemlos und wie gewünscht.

Kann mich jemand erleuchten wo ich hier die Tomaten auf den Augen habe?

Danke.

Britzel
- pq
  
  2013-11-04 16:43
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  ich nehme an, in der ersten variante wird der iterator jedesmal neu erstellt und fängt immer von vorne an.
  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
- Muffi
  
  2013-11-04 16:43
  
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  
  Ich bin jetzt nicht der große DBIx::Class Experte, aber ich kann mir vorstellen, dass $row->art2atts wohl das Resultset-Objekt jedes mal neu erstellt. Und next zeit dann jedesmal auf den gleichen Eintrag.
  1 + 1 = 10
  - +4 replies
  - jan
    
    2013-11-04 17:01
    User since
    2003-08-04
    2536 Artikel
    ModeratorIn
    
    davon gehe ich auch aus. Dann würde irgendwas helfen wie
    
    Code: (dl )
    
    for my $inner_row ($row->art2atts->all()) {
    
    oder eben gleich
    
    Code: (dl )
    
    for my $inner_row ($row->art2atts()) {
    
    kommt natürlich darauf an, wie groß das RS ist, u.u. macht ein's mit cursor ja auch sinn (was Du hier aber vermutlich eh nicht hast).
    Last edited: 2013-11-04 17:02:54 +0100 (CET)
    - +3 replies
    - Britzel
      
      2013-11-04 17:14
      
      User since
      2012-10-02
      20 Artikel
      BenutzerIn
      
      Ok, ich machs nun mit ner for-Schleife, das geht problemlos.
      Danke, auch an muffi & pq.
      
      - Edit -
      Zu früh gefreut. Das verwendete Templating-System (XSlate) kennt zwar for-loops, liefert aber möglicherweise nicht den richtigen Context. So wird $row->art2atts nicht als array-ref erkannt, damit weigert sich die Schleife in der Template zu laufen. Einen typecast oder Ähnliches kennt Xslate auch nicht.
      
      Und mein o.g. Workaround mit ner Zuweisung des ResultSet-Objects an ne Variable kann Xslate wie gesagt auch nicht.
      
      Ich verfluche den Tag an dem ich mich für Xslate entschieden habe :) Geschwindigkeit hin oder her... mit TT oder den Mojolicious-eigenen Templates wäre das alles schon längst fertig. Und jetzt noch umzustellen würde zu viel Zeit in Anspruch nehmen. Mift.
      
      Dennoch habe ich das nun hinbekommen, durch dieses Problem war ich mal wieder in den Tiefen der DBIC Doku unterwegs.
      
      Mit for my $inner_row ( $row->art2atts->get_cache() ) geht's nun, das liefert ein arrayref, mit dem XSlate was anfangen kann. Mal sehen, was das für Konsequenzen oder Nebeneffekte haben kann.
      
      Gruß,
      Britzel
      Last edited: 2013-11-04 17:48:15 +0100 (CET)
      - +2 replies
      - jan
        
        2013-11-04 23:32
        
        User since
        2003-08-04
        2536 Artikel
        ModeratorIn
        
        Könntest Du nicht vorher $results = [$row->art2atts()] setzen und dann $results an XSlate übergeben?
        Ich habe das noch nie benutzt, ich bin trotz aller hübschen Modernitäten immer noch bei TT, wenngleich mich da auch so manches stört und ich die Syntax, um zu casten, auch extrem hässlich finde. Sowas wie
        
        Code: (dl )
        
        [% c.req.scalar.headers.scalar.header("User-Agent") %]
        
        ist einfach unschön.
        
        Britzel
        
        2013-11-05 07:56
        
        User since
        2012-10-02
        20 Artikel
        BenutzerIn
        
        Ja, das geht natürlich auch.
        
        Bisher war mein Ansatz, das ich im Model einfach das ResultSet erzeuge und an die Template übergebe, fertig. Simpel & einfach. Das geht nicht überall und immer, klar, aber ich wollte schon versuchen das so lange wie möglich durchzuhalten.
        Anyway, nun geht's ja, nur halt nicht allgemeingültig. TT hat einige Schwächen, aber ist dafür 10x besser dokumentiert, und es gehen solche Sachen wie von Dir beschrieben _überhaupt_ :) Das ist schon ein großer Fortschritt ggü. XSlate.
        
        Gruß,
        Britzel

View all threads created 2013-11-04 16:20.