[pyar] Python ORM

[fisa]

On Apr 24, 2012 7:50 AM, "Roberto Alsina" <ralsina en netmanagers.com.ar>
wrote:
>
> 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.
>

Ni, porque en algunos ORMs (ej: django) es posible mandar una query a mano
y decirle que nos convierta el resultado a objetos de algún tipo, así que
hasta a veces podemos resolver esas querys manuales sin escribir el código
feo para manejar sus resultados.

Ej:

r = Pedido.objects.raw(sql_complejo_a_mano)

for pedido in r:
    print pedido.usuario.nombre

--
fisa - Juan Pedro Fisanotti

>> 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.
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
Argentina - http://www.usla.org.ar
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20120424/0a294cd2/attachment.html>