[Python] O non capisco sqlite, o non capisco sqlalchemy, o entrambi

[Pietro Battiston]

Il giorno mar, 19/11/2013 alle 16.10 +0100, Manlio Perillo ha scritto:
> On 19/11/2013 11:01, Pietro Battiston wrote:
> > [...]
> > A parte gli scherzi: non dico che l'ORM di SQLAlchemy sia _semplice_, ma
> > non l'ho mai trovato tanto più complesso di quanto lo fossero le mie
> > esigenze.
> >
> >> Un ultimo consiglio è di non usare l'ORM a meno di non aver bisogno
> >> veramente delle sue funzionalità (ossia in quei casi in cui dovresti
> >> reimplementarti le query non banali a mano); non è questo il tuo caso,
> >> quindi usa sqlalchemy.schema e sqlalchemy.sql, che è comunque conveniente.
> >>
> >
> > OK, OK, uso l'ORM perché non conosco SQL... ma _anche_ perché mi fa
> > risparmiare parecchio codice, e perché preferisco passare istanze che
> > id/righe... non è una motivazione molto pythonica?!
> >
> 
> Che intendi?
> 
> > Per quello ne ho capito io, _la_ funzionalità dell'ORM è mappare righe
> > in oggetti... e non riesco a pensare ad un caso in cui _non_ ne abbia
> > "bisogno veramente".
> >
> 
> Non hai bisogno di mappare tuple (nel senso usato in algebra 
> relazionale) in oggetti.
> L'oggetto che SQLAlchemy ti restituisce dopo una query è perfettamente 
> usabile:
> 
> r = sql.select([my_table], where=[...]).fetchall()
> for row in r:
>    for col in row:
>      print col
> 
> oppure:
> for row in r:
>     print row['id'], row['rel']


Sì, questo mi è chiaro, ma a me piace più un

    print mio_ogg.id, mio_ogg.rel

... a te no?! Perché se sto parlando di utenti e loro informazioni, di
città e loro posizioni, e più in generale di oggetti e loro proprietà,
dovrei scrivere di righe e loro elementi?!

Posso concepire (anche se francamente non ne ho esperienza) la presenza
di tabelle puramente accessorie, che non si mappino a nessun oggetto che
nella mia organizzazione mentale/del codice abbia senso considerare come
tale, e contemporaneamente non siano semplicemente secondary table di
relazioni. In quel caso - sparo - probabilmente sarei portato ad
utilizzare SQLAlchemy core _a fianco_ dell'ORM...

> 
> Con l'ORM hai il vantaggio che ti "aggrega" le tuple delle tabelle 
> "collegate", a seconda del tipo di relazione usata.  Nell'esempio fatto 
> prima row['rel'] sarà l'id della colonna collegata se usi sqlalchemy 
> core; con l'ORM sarà un dict-like contenente tutti i dati, oppure una 
> sequenza di dict-like nel caso di relazioni uno a molti.


Appunto... e anche nei casi in cui (poniamo) non ho tabelle collegate,
con l'ORM la classe me la definisco io, posso aggiungerle dei metodi che
mi servono, e farlo mano a mano che ne ho bisogno, posso definirla come
subclass di qualcos'altro, posso tenere distinti più facilmente i
refactoring che eventualmente dopo un po' io volessi fare al codice che
lavora sugli oggetti e quelli che voglio fare alla struttura del
database (magari tutto ciò lo posso fare in qualche modo anche senza
l'ORM, ma l'ORM mi sembra lo strumento naturale, no?)...

... poi ad un livello più di principio, per me l'ORM è ciò che permette
di usare un database ragionando ad oggetti, e la cosa, a meno di
controindicazioni che ancora mi sfuggono, mi piace.

ciao

Pietro