Discussion:
Django .update() con expresion F()
(too old to reply)
Tim Zenderman
2014-05-22 16:46:02 UTC
Permalink
Hola ***@s!

En un proyecto de django, estoy necesitando hacer un UPDATE en una tabla.
Este update en particular llevaría una sintaxis de django asi:

Entry.objects.update(headline=F('blog__name'))

donde la tabla Entry tiene FK a la tabla Blog. El problema es que django no
lo soporta: https://code.djangoproject.com/ticket/14104

Aca va información sobre la expresión F() de django:
https://docs.djangoproject.com/en/dev/ref/models/queries/#f-expressions

Se podrá hacer algo asi en SQL puro? Encontré este link aca:
http://stackoverflow.com/questions/12518560/django-update-table-using-data-from-another-tablepero
no conosco suficiente de SQL...

Alguna vez alguien tuvo que hacer algo asi? Como lo resolvieron?

--
Best,
Tim Z
BananaDesk
bananadesk.com/
<https://www.facebook.com/banana.desk.pms> <https://twitter.com/BananaDesk_en>
<http://www.pinterest.com/bananadesk/>
Ariel Camino
2014-05-22 17:55:43 UTC
Permalink
El 22/05/14 13:46, Tim Zenderman escribió:
> Hola ***@s!
>
> En un proyecto de django, estoy necesitando hacer un UPDATE en una
> tabla. Este update en particular llevaría una sintaxis de django asi:
>
> Entry.objects.update(headline=F('blog__name'))
>
> donde la tabla Entry tiene FK a la tabla Blog. El problema es que django
> no lo soporta: https://code.djangoproject.com/ticket/14104
>
> Aca va información sobre la expresión F() de
> django: https://docs.djangoproject.com/en/dev/ref/models/queries/#f-expressions
>
> Se podrá hacer algo asi en SQL puro? Encontré este link
> aca: http://stackoverflow.com/questions/12518560/django-update-table-using-data-from-another-table
> pero no conosco suficiente de SQL...
>
> Alguna vez alguien tuvo que hacer algo asi? Como lo resolvieron?
>
> --
> Best,
> Tim Z
> BananaDesk
> bananadesk.com/ <http://bananadesk.com/>
> <https://www.facebook.com/banana.desk.pms> <https://twitter.com/BananaDesk_en> <http://www.pinterest.com/bananadesk/>
>
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>

Hola Tim, si entendí bien, se me ocurren dos opciones, la obvia, lenta y
objetosa:

for entry in Entry.objects.all():
entry.headline = entry.blog.name

la cruda, rápida y base dependiente:

[...]
cursor.execute('UPDATE tuapp_entry LEFT JOIN tuapp_blog ON
tuapp_entry.blog_id=tuapp_blog.id SET tuapp_entry.headline=tuappblog.name')

algo así debería funcionar, no lo probé.

Suerte!
--
Ariel Camino
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Tim Zenderman
2014-05-22 18:12:06 UTC
Permalink
Hola Ariel! Si, el problema con hacer el for es que son 150.000 objetos y
hay señales que se ejecutan con cada save entonces termina siendo muyyyy
lento (muchas horas).


2014-05-22 13:55 GMT-04:00 Ariel Camino <arielcamino-***@public.gmane.org>:

> El 22/05/14 13:46, Tim Zenderman escribió:
> > Hola ***@s!
> >
> > En un proyecto de django, estoy necesitando hacer un UPDATE en una
> > tabla. Este update en particular llevaría una sintaxis de django asi:
> >
> > Entry.objects.update(headline=F('blog__name'))
> >
> > donde la tabla Entry tiene FK a la tabla Blog. El problema es que django
> > no lo soporta: https://code.djangoproject.com/ticket/14104
> >
> > Aca va información sobre la expresión F() de
> > django:
> https://docs.djangoproject.com/en/dev/ref/models/queries/#f-expressions
> >
> > Se podrá hacer algo asi en SQL puro? Encontré este link
> > aca:
> http://stackoverflow.com/questions/12518560/django-update-table-using-data-from-another-table
> > pero no conosco suficiente de SQL...
> >
> > Alguna vez alguien tuvo que hacer algo asi? Como lo resolvieron?
> >
> > --
> > Best,
> > Tim Z
> > BananaDesk
> > bananadesk.com/ <http://bananadesk.com/>
> > <https://www.facebook.com/banana.desk.pms> <
> https://twitter.com/BananaDesk_en> <http://www.pinterest.com/bananadesk/>
> >
> >
> > _______________________________________________
> > pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> > 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
> >
>
> Hola Tim, si entendí bien, se me ocurren dos opciones, la obvia, lenta y
> objetosa:
>
> for entry in Entry.objects.all():
> entry.headline = entry.blog.name
>
> la cruda, rápida y base dependiente:
>
> [...]
> cursor.execute('UPDATE tuapp_entry LEFT JOIN tuapp_blog ON
> tuapp_entry.blog_id=tuapp_blog.id SET tuapp_entry.headline=tuappblog.name
> ')
>
> algo así debería funcionar, no lo probé.
>
> Suerte!
> --
> Ariel Camino
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>



--
Best,
Tim Z
BananaDesk
bananadesk.com/
<https://www.facebook.com/banana.desk.pms> <https://twitter.com/BananaDesk_en>
<http://www.pinterest.com/bananadesk/>
Martín Gaitán
2014-05-22 18:21:58 UTC
Permalink
2014-05-22 15:12 GMT-03:00 Tim Zenderman <tim-***@public.gmane.org>:

> Hola Ariel! Si, el problema con hacer el for es que son 150.000 objetos y
> hay señales que se ejecutan con cada save entonces termina siendo muyyyy
> lento (muchas horas).


for entry in Entry.objects.all():
entry.headline = entry.blog.name
entry.save(update_fields=['headline'])


Eso no te sirve? sólo estás haciendo el update de ese campo (y no de todo
lo que tenga el modelo Entry) y en tu receiver podés ignorar las señales
post_save que vengan con este campo solo (post_save manda como argumento
update_fields)

https://docs.djangoproject.com/en/dev/ref/signals/#post-save

si estás haciendo una consulta extra para traer los campos de entry.blog
pero quizas podés optimizar un poquito más usando select_related

https://docs.djangoproject.com/en/dev/ref/models/querysets/#select-related

150mil instancias no suena mucho para meterse con raw_queries, creo que
embarrarse las patas muy temprano.

saludos

--
mgaitan.github.io
textosypretextos.com.ar <http://textosyprextextos.com.ar>
Luis Masuelli
2014-05-22 19:47:52 UTC
Permalink
Hay alguna aplicacion externa que permita editar actualizar campos relacionados?

From: gaitan-***@public.gmane.org
Date: Thu, 22 May 2014 15:21:58 -0300
To: pyar-+ZN9ApsXKcFd+***@public.gmane.org
Subject: Re: [pyar] Django .update() con expresion F()

2014-05-22 15:12 GMT-03:00 Tim Zenderman <tim-***@public.gmane.org>:


Hola Ariel! Si, el problema con hacer el for es que son 150.000 objetos y hay señales que se ejecutan con cada save entonces termina siendo muyyyy lento (muchas horas).
for entry in Entry.objects.all():



entry.headline = entry.blog.name
entry.save(update_fields=['headline'])



Eso no te sirve? sólo estás haciendo el update de ese campo (y no de todo lo que tenga el modelo Entry) y en tu receiver podés ignorar las señales post_save que vengan con este campo solo (post_save manda como argumento update_fields)



https://docs.djangoproject.com/en/dev/ref/signals/#post-save
si estás haciendo una consulta extra para traer los campos de entry.blog


pero quizas podés optimizar un poquito más usando select_related

https://docs.djangoproject.com/en/dev/ref/models/querysets/#select-related



150mil instancias no suena mucho para meterse con raw_queries, creo que embarrarse las patas muy temprano.

saludos



--
mgaitan.github.io
textosypretextos.com.ar




_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Leandro Poblet
2014-05-22 20:14:56 UTC
Permalink
El 22 de mayo de 2014, 16:47, Luis Masuelli <luismasuelli-***@public.gmane.org>escribió:

> Hay alguna aplicacion externa que permita editar actualizar campos
> relacionados?
>

http://www.devjoker.com/contenidos/catss/16/Actualizacion-de-datos-UPDATE.aspx

SQL es un golazo para eso.
Luis Masuelli
2014-05-23 00:44:56 UTC
Permalink
Es un golazo hasta que por alguna razon tenes que cambiarte de una BD a otra. 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.

Date: Thu, 22 May 2014 17:14:56 -0300
From: leandrodrhouse-***@public.gmane.org
To: pyar-+ZN9ApsXKcFd+***@public.gmane.org
Subject: Re: [pyar] Django .update() con expresion F()

El 22 de mayo de 2014, 16:47, Luis Masuelli <luismasuelli-***@public.gmane.org> escribió:




Hay alguna aplicacion externa que permita editar actualizar campos relacionados?

http://www.devjoker.com/contenidos/catss/16/Actualizacion-de-datos-UPDATE.aspx


SQL es un golazo para eso.


_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
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
Leandro Poblet
2014-05-23 12:07:30 UTC
Permalink
El 22 de mayo de 2014, 21:44, Luis Masuelli <luismasuelli-***@public.gmane.org>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.
Claudio Omar Melendrez Baeza
2014-05-23 13:41:06 UTC
Permalink
+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-***@public.gmane.org>:

> El 22 de mayo de 2014, 21:44, Luis Masuelli <luismasuelli-***@public.gmane.org>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-+ZN9ApsXKcFd+***@public.gmane.org
> 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
>
Claudio Omar Melendrez Baeza
2014-05-23 13:42:22 UTC
Permalink
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-***@public.gmane.org>:

> +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-***@public.gmane.org>:
>
>> El 22 de mayo de 2014, 21:44, Luis Masuelli <luismasuelli-***@public.gmane.org>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-+ZN9ApsXKcFd+***@public.gmane.org
>> 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
>>
>
>
Luis Masuelli
2014-05-23 14:14:33 UTC
Permalink
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-***@public.gmane.org
To: pyar-+ZN9ApsXKcFd+***@public.gmane.org
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 <***@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-***@public.gmane.org>:


El 22 de mayo de 2014, 21:44, Luis Masuelli <luismasuelli-***@public.gmane.org> 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-+ZN9ApsXKcFd+***@public.gmane.org

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-+ZN9ApsXKcFd+***@public.gmane.org
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
Loading...