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

[Pietro Battiston]

Il giorno mar, 19/11/2013 alle 17.55 +0100, Manlio Perillo ha scritto:
> On 19/11/2013 17:30, Pietro Battiston wrote:
> > [...]
> >> 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
> >
> 
> La differenza tra
> 
>         print row['id'], row['rel']
> 
> è solo di "facciata", specialmente se tieni conto che, in realtà, quello 
> che tu hai scritto è equivalente, in Python, a:
> 
>         print mio_ogg.__dict__['id'], mio_ogg.__dict__['rel']


Sì, sì, certo! Ti sto solo dicendo quale facciata preferisco...


> > ... 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?!
> >
> 
> Perchè è quello che realmente sono, visto che sono memorizzati in un 
> database relazionale.

... ma mi piacciono le facciate! Ovviamente, non tanto da sacrificare
l'efficienza.

> 
> E non si parla di righe e loro elementi, ma semplicemente di righe 
> (anche se il termine corretto sarebbe tupla).
> Anche con l'ORM ti restituisce una lista di oggetti, no?
> 

Certo... ma sono gli oggetti con cui sto ragionando, non altri necessari
per l'implementazione del mio ragionamento...


> > [...]
> > Appunto... e anche nei casi in cui (poniamo) non ho tabelle collegate,
> > con l'ORM la classe me la definisco io,
> 
> Perchè, la tabella SQL no?
> 

Beh, sì... ma se non sbaglio il python è un linguaggio ad oggetti, non a
tabelle :-)

> > posso aggiungerle dei metodi che
> > mi servono,
> 
> Puoi anche definire funzioni libere, che operano sulla tuple (perchè 
> tanto in Python i metodi sono funzioni libere, alla fine).

... ci deve essere davvero qualcosa di grosso che mi sfugge se, mentre
cerco di organizzare il mio codice in ordinate classi, un veterano (del
Vietnam? ;-) ) mi dice che in Python posso "anche definire funzioni
libere"...

> 
> > e farlo mano a mano che ne ho bisogno, posso definirla come
> > subclass di qualcos'altro,
> 
> L'ORM offre alcuni pattern complessi per diverse situazioni.
> Però, come ti ha detto Nicola, non è tutto "rose e fiori".
> 

OK, infatti ora mi leggo il materiale che ha passato.

> > 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?)...
> >
> 
> Se devi fare refactoring, ci sono metodi ben noti a livello di SQL.
> 

Non ne dubito...

> > ... 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.
> >
> 
> E' attrattivo certamente.
> Ma non bisogna abusarne; io ti ho avvertito poi sei libero di fare come 
> voi (ma il consiglio di imparare prima SQL resta, altrimenti se qualcosa 
> non funziona/è inefficiente avrai grosse difficoltà).
> 

Certo, la tua raccomandazione di capire cosa succede sotto è sacrosanta,
non lo metto assolutamente in dubbio (anche se il tradeoff tra quanto ti
studi l'implementazione delle librerie che usi e quanto tempo ti rimane
per fare quello che dovevi fare è particolarmente importante per chi non
programma di professione).

Quello che mi incuriosiva era solo lo step successivo, "evita ORM se
possibile"... e ora dovrei avere di che riflettere.

grazie!

Pietro