[pyar] Django .update() con expresion F()

[Luis Masuelli]

Si, no sera mucha diferencia pero en realidad la hay. El ejemplo concreto es justamente esto: actualizaciones cruzadas. En MySQL es distinto que en Oracle:

UPDATE a INNER JOIN b ON (...) SET ... WHERE ...; --en mysql

contra

UPDATE (SELECT a INNER JOIN b ON (...) WHERE ...) SET ...; --en oracle

El tema empeora un poco si la relacion cruzada tiene más de 2 niveles (este caso se aplicaría a ejemplos como .update(price=F('product__price')) si tal cosa se soportara en django, pero traeria problemas si hablamos de algo como .update(price=F('product__base_product__price')) suponiendo un ecommerce en el que uno adquiere una variacion de un producto; tomese como un simple ejemplo nomas).

Date: Fri, 23 May 2014 10:42:22 -0300
From: claudio.melendrez en gmail.com
To: pyar en python.org.ar
Subject: Re: [pyar] Django .update() con expresion F()

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





_______________________________________________
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/31f772dc/attachment.html>