[pyar] Python ORM

[Roberto Alsina]

On 04/24/2012 06:48 AM, Ricardo Araoz wrote:
> El 24/04/12 02:33, Claudio Freire escribió:
>> 2012/4/23 Emiliano Dalla Verde Marcozzi<edvm en member.fsf.org>:
>>> Lo de "propio" significa que no lo podes compartir ? :)
>> Me daría vergüenza :p
>>
>> Viene con chanchadas hechas para pluguear limitaciones de SQLAlchemy
>> 0.3.1, imaginate, y compatibilizado con 0.5.8. No funca con 0.7.x, y
>> no está usando muchas de las cosas que tiene 0.5.8 porque ya hay
>> código hecho para 0.3.1 que lo hace.
>>
>> O sea, feíto. Útil para nosotros, pero creo que en gran parte
>> supersedido por la capa declarativa de SA 0.7.x.
>>
>> Si lo empezara desde cero, sería muy diferente, y seguramente compartible.
>
> Hola, manejo sql muy bien y generalmente en mi área tengo que lidiar con
> queries complejas. Nunca usé un ORM.  Las veces que intenté aprender uno
> me pareció antinatural y complicado para expresar queries (no para usar
> los resultados) y me quedé con la impresión que los queries complejos no
> se podían expresar de esa forma.

Para la gran mayoría de los casos, el ORM va a soportar el query que
se necesita. Y sí, si no es así, hacés el SQL a mano.

> Ya se que también tienen la posibilidad
> de mandar el query en SQL directamente, pero entonces para qué necesito
> el ORM?

Para no tener que rearmar los objetos a partir del resultado del SQL, 
con lo que eliminás una pila de código aburrido y que tiende a ser
fuente de errores.

Para los casos en los que *no* tenés que hacer el SQL a mano.

> La otra ventaja que supuse que tendría es no tener que
> preocuparme por las diferencias entre los DDLs de los distintos motores
> (el SQL en general es bastante standard) pero leyendo el hilo veo que
> no, que hay que preocuparse por si el ORM soporta un motor de base de
> datos particular y encima por la compatibilidad con las distintas
> versiones del ORM.

Lo de la compatibilidad: es cierto. Es una cosa que me molestó en 
SQLAlchemy, pero de hecho me llamó la atención ahí porque NO es
algo que pase habitualmente.

Y sí, para usar una base de datos determinada, necesitás un ORM que la 
soporte, igual que para usar SQL necesitás un driver que la soporte, e
igual que si tenés drivers para dos bases tenés linduras como que no
soporten el mismo mecanismo para preparar queries.

Usar un ORM necesita buy-in. Tenés que querer usarlo, tenés que pagar
un costo para sacarle el jugo, y si no te gusta, bueno, es un costo que
tiraste a la basura. Si preferís usar SQL pelado: bárbaro.

> Mi conclusión es que es mucho mejor aprender bien una forma de expresar
> queries (SQL), mantener el DDL todo junto, y bancarse los pequeños
> cambios necesarios al cambiar de DBE.

Esa conclusión no la comparte casi nadie que haya usado un ORM (o un 
DAL) en un proyecto de verdad.