4. Usare ed estendere il modulo

In generale probabilmente è una scelta saggia non interagire direttamente con l'API DB, eccetto che per piccole applicazioni. I database, anche SQL, variano ampiamente per capacità e possono avere varie caratteristiche non-standard. L'API DB fa un buon lavoro nel fornire un'interfaccia ragionevolmente portabile, ma alcuni metodi non sono portabili. Nello specifico i parametri accettati da connect() sono assolutamente dipendenti dall'implementazione.

Se si crede che l'applicazione debba girare su diversi database, raccomando l'approccio seguente, basato sulla mia esperienza personale: si scriva un'API semplificata per la propria applicazione, che implementi le particolari interrogazioni e operazioni che l'applicazione deve usare. Si implementi tale API come classe base, che dovrebbe avere poche dipendenze dal database, e quindi se ne derivi una sottoclasse che implementi le dipendenze necessarie. In questo modo, portare la propria applicazione su un nuovo database dovrebbe essere una questione semplice, basta creare una nuova sottoclasse, dando per scontato che il nuovo database sia ragionevolmente standard.

Per un esempio di tutto ciò si veda il modulo SQLDict dell'autore, che permette la definizione e l'accesso a interrogazioni standard usando un oggetto che somiglia a un dizionario e legge/scrive oggetti definiti dall'utente.

Dato che gli oggetti Connessione e Cursore di MySQLdb sono scritti in Python, è semplice derivare le proprie sottoclassi. Ci sono diverse classi Cursor in MySQLdb.cursors:

BaseCursor

la classe base per gli oggetti Cursore. Non solleva eccezioni Warning.

CursorWarningMixIn

in caso di avvisi prodotti da interrogazioni solleva un'eccezione Warning.

CursorStoreResultMixIn

fa sì che il Cursore usi la funzione mysql_store_result() per ricevere il risultato della interrogazione. L'intero risultato viene memorizzato dal lato client della connessione.

CursorUseResultMixIn

fa sì che il Cursore usi la funzione mysql_use_result() per ricevere il risultato dell'interrogazione. Il risultato è memorizzato sul lato server e trasferito riga per riga con operazioni di prelievo.

CursorTupleRowsMixIn

fa sì che il Cursore restituisca le righe come una tupla dei valori della colonna.

CursorDictRowsMixIn

fa sì che il Cursore restituisca le righe come un dizionario, dove le chiavi sono i nomi delle colonne e i valori sono i valori della colonne. Si noti che se i nomi delle colonne non sono unici, per dire si sta effettuando una selezione da due tabelle che condividono i nomi delle colonne, alcuni nomi verranno riscritti come tabella.colonna. Lo si può evitare usando la parola chiave SQL AS. (Questa è un'ulteriore ragione per non usare * nelle interrogazioni SQL, specialmente quando è implicato un JOIN).

Cursor

la classe cursore di default. Questa classe è composta da CursorWarningMixIn, CursorStoreResultMixIn, CursorTupleRowsMixIn e BaseCursor, perciò solleva Warning, usa mysql_store_result() e restituisce le righe come tuple.

DictCursor

simile a Cursor, eccetto che restituisce le righe come dizionari.

SSCursor

un cursore lato server. Simile a Cursor ma utilizza CursorUseResultMixIn. Lo si usi solo in caso si abbia a che fare con risultati potenzialmente di grandi dimensioni.

SSDictCursor

simile a SSCursor, eccetto che restituisce le righe come dizionari.

XXXCursorNW

i cursori col suffisso "NW" non sollevano avvisi.

Per un esempio di come usare queste classi, si legga il codice. Se si ha bisogno di cose più esotiche, si dovrà fare da sè.