PowerRuby: accesso al DB2 (Parte 1)

Nell’incontro organizzato da FAQ400 il 21 Novembre del 2019 ho tenuto una presentazione sull’uso di PowerRuby per generare fogli Excel con dati pre-caricati da IBM i. Ho pensato di ricavarne due brevi articoli da pubblicare. Oggi ci occupiamo unicamente dell’accesso al DB2.

Per l’installazione di PowerRuby esiste già un mio precedente contributo. (PowerRuby CE2 – Ndr)

Ricordiamo qui solamente che per verificare la installazione è sufficiente aggiungere la libreria POWER_SLNG alla lista delle librerie e richiamare il comando DSPSFWRSC.

Scorrendo l’elenco dei prodotti installati si dovrebbe arrivare alla risorsa 1PRUBY1. 

Le seguenti opzioni sono necessarie per le funzioni descritte nel presente articolo.

                        Visualizzazione risorse software                       
                                                          Sistema:   XXXXX400  
  ID  
  risorsa  Opz.   Dispos.  Descrizione      
  1PRUBY1  *BASE   5001    IBM i PowerRuby (administration utilities)  
  1PRUBY1  *BASE   2924    IBM i PowerRuby (administration utilities)         
  1PRUBY1  1       5002    IBM i PowerRuby Developer Edition (irubydb) 
  1PRUBY1  6       5001    IBM i PowerRuby (Ruby 2.4 + Rails 5.1)              

L’aspetto affascinante di Rails è sicuramente il motore ORM (Object-Relational Mapping) che è costituito dal componente noto col nome di  ActiveRecords.

Al di la dei problemi teorici di coesistenza tra modello relazionale e programmazione object-oriented, che generano il cosiddetto object-relational impedence mismatch (vedi Wikipedia, classe di problemi a cui i diversi ORM hanno cercato di ovviare) qui ci interessa -molto pragmaticamente- vedere cosa sia possibile fare, con poco sforzo, su IBM i.

Come è noto molti comandi di sistema IBM i offrono l’opzione OUTPUT(*OUTFILE) che ci consente di estrarre su un file di database il contenuto risultante.

Nella presentazione di Milano avevo preso in considerazione il comando DSPFFD applicandolo su un file particolarmente interessante: il file QSYS/QADBXLFI.

Innanzi tutto utilizziamo una buona shell comandi (ultimamente mi sono entusiasmato del supporto Terminal offerto dal progetto Open Source Jupyter Lab) e verifichiamo che sia ruby che rails siano accessibili:

bash-4.4$ /PowerRuby/prV2R4/bin/ruby -v
ruby 2.4.4p296 (2018-03-28 revision 63013) [powerpc-aix7.1] 

 bash-4.4$ /PowerRuby/prV2R4/bin/rails -v 
 Rails 5.1.6 

Preliminarmente generiamo nella libreria corrente un file di nome CLEVER con il comando DSPFFD:

bash-4.4$ system "DSPFFD FILE(QSYS/QADBXLFI) OUTPUT(*OUTFILE) OUTFILE(*CURLIB/CLEVER)"

Possiamo ora prendere dimestichezza con Ruby attraverso l’interprete interattivo (Interactive RuBy = irb):

bash-4.4$ /PowerRuby/prV2R4/bin/irb
 irb(main):001:0>  

ActiveRecord può essere utilizzato anche svincolato da Rails ma per richiederne le funzioni occorre richiamarne la gemma col comando require:

irb(main):001:0> require 'active_record'
 => true 

Ora possiamo definire una variabile di tipo Hash in cui registrare i parametri di configurazione per l’accesso al database:

irb(main):002:0> conf = {:adapter => "irubydb", 
 irb(main):003:1*         :database => '*LOCAL',  
 irb(main):004:1*         :default_schema => '*LIBL', 
 irb(main):005:1*         :username => '*CURRENT',  
 irb(main):006:1*         :password => ''} 
 => {:adapter=>"irubydb", :database=>"*LOCAL", :default_schema=>"*LIBL", :username=>"*CURRENT", :password=>""} 

Queste informazioni serviranno per interagire con un’altra gemma che verrà implicitamente caricata (la irubydb, parte del progetto PowerRuby). 

Con queste impostazioni utilizzeremo l’SQL inline (non il server mode) beneficiando anche della lista delle librerie corrente e delle autorizzazioni ai file proprie dell’utente attivo. Il metodo che ci occorre (establish_connection) è -evidentemente- offerto da una classe (Base) del componente ActiveRecord che abbiamo richiamato con successo nel passo precedente (require):

irb(main):007:0> conn = ActiveRecord::Base.establish_connection(conf) 

Ora faremo un doppio sub-classing.

Prima deriviamo la classe ApplicationRecord dalla ActiveRecord::Base, conservandone la natura astratta.

Successivamente deriviamo la classe Description dalla ApplicationRecord, impostando il nome della tabella al valore ‘clever’ (impostante l’uso del minuscolo).

class ApplicationRecord < ActiveRecord::Base
 self.abstract_class = true 
 end 
 class Description < ApplicationRecord  
 self.table_name = 'clever'    
 end   

Questo consente alla classe Description di ereditare tutti i metodi previsti da ActiveRecord: la cosa sorprendente è che possiamo già interagire con i record della tabella CLEVER:

s = Description.all()

Ora con la funzione map  possiamo interagire con il risultato (appoggiato nella variabile s) filtrando solo alcuni campi (il nome del campo –WHFLDI– e la descrizione –WHFTXT-). 

Dell’array restituito possiamo mostrare solo alcuni record (qui i primi 3).

s.map{|h| [h.whfldi, h.whftxt]}[0..2]

Nella seconda parte dell’articolo tratteremo i record del file CLEVER per generare con essi un foglio Excel servendoci di una gemma addizionale che vedremo come installare.