[pyar] [django] como achicar los queries?

xavier lesa xavierlesa en gmail.com
Sab Sep 18 13:22:24 ART 2010


buenisimo!! eso es lo que estaba buscando..
con respecto al user.get_profile() encontre un patch [0] que ya lo resuelve.

[0] http://code.djangoproject.com/ticket/4196
 <http://code.djangoproject.com/ticket/4196>
Xavier Lesa

Desarrollo y Tecnología
Personal: +11 15 3868 3918
Skype: xavierlesa


2010/9/17 QliX=D! [aka EHB] <qlixed en gmail.com>

> Es mas, podes crear un manager[0] que por defecto para la clase que
> vos necesitas te devuelva siempre los objetos "related".
> Leyendo un poco el codigo del manager (/trunk/django/db/models/manager.py):
>
> 46      class Manager(object):
> 47          # Tracks each time a Manager instance is created. Used to
> retain order.
> 48          creation_counter = 0
> 49
> 50          def __init__(self):
> 51              super(Manager, self).__init__()
> 52              self._set_creation_counter()
> 53              self.model = None
> 54              self._inherited = False
> 55              self._db = None
> [...]
> 107         def get_query_set(self):
> 108             """Returns a new QuerySet object.  Subclasses can
> override this method
> 109             to easily customize the behavior of the Manager.
> 110             """
> 111             return QuerySet(self.model, using=self._db)
> [...]
> 116         def all(self):
> 117             return self.get_query_set()
> [...]
> 137         def create(self, **kwargs):
> 138             return self.get_query_set().create(**kwargs)
> 139
> 140         def filter(self, *args, **kwargs):
> 141             return self.get_query_set().filter(*args, **kwargs)
> [...]
> 167         def select_related(self, *args, **kwargs):
> 168             return self.get_query_set().select_related(*args, **kwargs)
> [...]
>
> Si Haces algo como:
>
> [...]
> 140         def filter(self, *args, **kwargs):
> 141             return self.get_query_set().filter(*args,
> **kwargs).select_related(*args, **kwargs)
> [...]
>
> Todos los filters q apliques con este manager aplican tambien un
> select_related.
>
> Saludos.
> EHB
>
> [0] Managers:
> http://docs.djangoproject.com/en/dev/topics/db/managers/#managers-for-related-objects
>
>
> 2010/9/17 xavier lesa <xavierlesa en gmail.com>:
> > y se podrá hacer eso mismo a través de otro modelo?, puntualmente desde
> el
> > modelo User al perfil, es decir
> > cuando hago un user.get_profile()
> >
> > ej:
> >
> > # obtengo el ContentObject, con la facilidad del select_related
> > co = ContentObject.objects.select_related().get(pk=1)
> >
> > # obtengo el perfil del usuario
> > co_profile = co.user.get_profile()
> >
> > # hago algo con el profile
> > co_profile.kill_em_all = u'Yeahhh'
> >
> >
> > Slds
> >
> > Xavier Lesa
> >
> > Desarrollo y Tecnología
> > Personal: +11 15 3868 3918
> > Skype: xavierlesa
> >
> >
> > 2010/9/17 xavier lesa <xavierlesa en gmail.com>
> >>
> >> Bien, select_related funciono muy bien. era justamente lo que buscaba.
> >> gracias!
> >>
> >> Xavier Lesa
> >>
> >> Desarrollo y Tecnología
> >> Personal: +11 15 3868 3918
> >> Skype: xavierlesa
> >>
> >>
> >> 2010/9/17 QliX=D! [aka EHB] <qlixed en gmail.com>
> >>>
> >>> 2010/9/16 xavier lesa <xavierlesa en gmail.com>:
> >>> > Hola gente, estoy teniendo un problemita cuando accedo al "perfil" de
> >>> > un
> >>> > usuario, haciendo la típica extensión del modelo User.
> >>> > básicamente tengo un modelo "contentobjects" que se relaciona con el
> >>> > modelo
> >>> > "user" y este con "user_profile" (quien lo extiende).
> >>> >
> >>> > class ContentObjects(models.Model):
> >>> >     user = models.ForeignKey(User)
> >>> >
> >>> > class UserProfile(models.Model):
> >>> >     user = models.ForeignKey(User)
> >>> >
> >>> > el problema es que cuando genero la vista de ContentObject y de la
> >>> > relación
> >>> > user "traigo" el user_profile, me genera 2 queries mas
> >>> > y esto en total sumando los queries propios de ContentObject me suma
> 45
> >>> > queries solo para 15 registros, y tengo que mostrar
> >>> > como 1500... haciendo un test muy básico de eso me llevo como 15 seg
> >>> > cargar
> >>> > todo.
> >>> >
> >>>
> >>> X q tenes 45 queries solo para ContentObject?, creo que el punto a
> >>> revisar es eso.
> >>> Si tenes que mostrar 1500, haces un select uno a uno de los objetos?
> >>> O sea, usando select related igualmente serian 15 queries para 15
> objetos
> >>> a
> >>> mostrar, es MUCHO igual, pasarias de 4500 a 1500 queries!.
> >>>
> >>>
> >>> > Entonces me preguntaba, si yo "replico" los campos -- rompiendo el
> >>> > principio
> >>> > DRY -- de user_profile en ContentObject me ahorraría esos queries
> >>> > demás, y solo para levantar esos 1500 registros usaría 5 queries..
> >>> >
> >>> > Ven esto como una practica "aceptable"? o creen que debería encararlo
> >>> > de una
> >>> > manera distinta? optimizando los queries talvés?
> >>>
> >>> A mi entender, no deberias hacerlo, deberias usar selected_related. y
> >>> revisar el
> >>> esquema de consulta.
> >>>
> >>>
> >>> EHB
> >>> _______________________________________________
> >>> 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/
> >>
> >
> >
> > _______________________________________________
> > 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/
> >
> _______________________________________________
> 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/
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20100918/b09d6fef/attachment.html>


More information about the pyar mailing list