[pyar] Python ORM
Juan Manuel Santos
vicariousdm en gmail.com
Lun Abr 23 15:56:35 ART 2012
On Monday, April 23, 2012 14:45:42 Claudio Freire wrote:
> 2012/4/23 Matigro <matigro en gmail.com>:
> > Yo realmente nunca vi la diferencia, las aplicaciones web que vi
> > andando no eran tan demandadas como para tomar una postura si entre un
> > framework y otro.
> > Además, SO 2 había mejorado mucho en velocidades y "objetosidad", pero
> > no lo estaban usando en TurboGears2.
>
> Mi experiencia fue con SQLObject de alto volumen, y no se la banca.
> SQLAlchemy se la banca mejor, igual, para el volumen que yo
> necesitaba, hacían falta hacks feos incluso para alchemy.
>
No es que no se la banca, es que a diferencia del ORM de Django, en donde
tenés que salvar específicamente si modificás algo, acá cada modificación a un
atributo de un objeto te triggerea un write. Si vos hacés
personita = Persona(name="Roberto")
personita.name = "Ricardo"
personita.name = "Ricaberto"
Eso te triggerea 3 writes bajo SQLO (no así bajo el ORM de Django por ejemplo.
Ahora si vos hacés (teniendo previamente la clase connection definida por algún
lado):
trans = connection.transaction()
personita = Persona(name="Roberto", connection = trans) # Sí, SQLO te deja
meter el parámetro connection por todos lados, incluso cuando el parámetro es
una transacción y no una connection propiamente dicha)
personita.name = ....
personita.name = ....
trans.commit()
Entonces vas a tener un sólo write. Lo se porque justamente laburé con SQLO y
SQLA/Elixir, haciendo un crawling de filesystems y guardando metadata, y no
entendía por qué SQLA era más rápido que SQLO, hasta que vi que pasaba por
esto de las transacciones.
Me fui al carajo, pero todo esto venía a que en definitiva ninguno es más
rápido per se (al menos no sustancialmente más rápido :)). Cuando tuve SQLO
funcionando con transacciones, anduvo igual de rápido que SQLA. Y por cómo
estaba diseñado el programa, necesitaba mantener distintas conexiones a
distintas dbs sqlite abiertas que bajo SQLA se hacía muy engorroso, whereas
bajo SQLO no.
Mis 2 ctvs.
Saludos
Juan Manuel
More information about the pyar
mailing list