Anssi
The last time I checked the use of IN, all the records from the database
in the query were brought back to the workstation, rather than being
processed on the backend and only the results returned to the workstation.
Have there been changes that carry out the entire query on the backend?
What has changed to cause you to prefer the use of the IN statement?
R+C
On 08/11/2013 05:55, akaariai wrote:
On Sunday, November 3, 2013 1:48:07 PM UTC+2, Robin St.Clair wrote:
*IN*
* if using Django avoid the IN operation at all costs
If there are potentially more than 15 items in the list, rework
the IN as a JOIN against whatever the source of the keys is
I don't necessarily agree with everything else said in the post, but
this one is just plain wrong. It is completely OK to use
__in=queryset. In fact, it is recommended in cases where the alternate
is using join + distinct.
- Anssi
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/6b5f9e3a-2e41-47b5-b0d6-94473fe323b8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/BLU0-SMTP357C2324CC6BEC3F975EB4AE2F20%40phx.gbl.
For more options, visit https://groups.google.com/groups/opt_out.
