[pyar] Django .update() con expresion F()
Claudio Omar Melendrez Baeza
claudio.melendrez en gmail.com
Vie Mayo 23 10:42:22 ART 2014
Correccion: "sin demasiadas != ninguna".
Ja, se nota la falta de cafe. A remediarlo.
2014-05-23 10:41 GMT-03:00 Claudio Omar Melendrez Baeza <
claudio.melendrez en gmail.com>:
> +1
>
> La realidad es que una abstraccion total de la DB no existe (y tal vez no
> deberia existir).
>
> Yo laburo hace casi un anno en un proyecto que usa Django+MongoDB con una
> version tuneada de django_mongodb_engine y el ~10% de los queries usan
> alguna forma "raw". El cambio de MySQL a MongoDB fue una pesadilla (aunque
> buena decision). Ahora salir de Mongo es efectivamente imposible, y no solo
> por los tipos de dato. Seria demasiado el codigo a tocar.
>
> Agradece que en el mundo *SQL hay un alto nivel de standardizacion y
> puedas cambiar de un sistema a otro sin "demasiadas dificultades". Pero
> demasiadas != ninguna.
> Como dice Leandro, saber el "lenguaje de la DB que usas" viene muy bien y,
> para cualquier sistema de complejidad media+, yo diria que es necesario.
>
>
>
> 2014-05-23 9:07 GMT-03:00 Leandro Poblet <leandrodrhouse en gmail.com>:
>
>> El 22 de mayo de 2014, 21:44, Luis Masuelli <luismasuelli en hotmail.com>escribió:
>>
>>> Es un golazo hasta que por alguna razon tenes que cambiarte de una BD a
>>> otra.
>>>
>>
>> Me sorprendería (y mucho) que algo tan pero tan básico como UPDATE cambie
>> en algún sistema de base de datos SQL (No puedo hablar de NoSQL porque
>> jamás los usé). Pero, si realmente necesitás usar django:
>>
>> Entry.objects.raw('UPDATE tuapp_entry LEFT JOIN tuapp_blog ON
>> tuapp_entry.blog_id=tuapp_blog.id SET tuapp_entry.headline=tuappblog.name
>> ')
>>
>> Cambiaría mínimamente pero no dependerías de 3 capas que resuelvan cada
>> consulta y por ende hacerlo cien o mil veces más lento de lo que necesita
>> serlo. A veces lo mejor es no depender de la aplicación para todo, una
>> charla muy interesante se dió en la Pycon 2012 al respecto:
>> http://www.slideshare.net/OReillyOSCON/unbreaking-your-django-application
>>
>>
>>> Pero, hasta donde yo se, SQL no es el nombre de una aplicación de django
>>> sino mas bien algo de lo que normalmente django nos salva.
>>>
>>
>> Saber SQL te puede salvar las papas de muchas cosas que, por desgracia,
>> un framework no puede resolver.
>>
>> _______________________________________________
>> 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/20140523/8aa051aa/attachment.html>
More information about the pyar
mailing list