Comments on: django queryset weirdness http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/ Stay Hungry. Stay Foolish! Fri, 05 Dec 2008 12:48:30 +0000 http://wordpress.org/?v=2.6.5 By: WorldMaker http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9519 WorldMaker Mon, 09 Apr 2007 22:46:56 +0000 http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9519 SmileyChris is correct *everytime* you slice a queryset it runs the query. That is: every u[0] is a different object, so u[0].save() just resaves exactly what's in the database already, because it refreshes on u[0]. Unfortunately, QuerySet just doesn't have any sort of "slice caching", so everytime you use [] you need to cache it yourself by saving it to a seperate name (in the case of a list, eg [:3], you want to pass it through list() to run the query if you aren't using a for loop). This should probably be better documented... (I've been bitten by this myself... One example I've yet to fix is the random photo link on my frontpage: due to the order_by('?') the random photo has an entirely different random alt tag and links to a further different random photo.) SmileyChris is correct *everytime* you slice a queryset it runs the query. That is: every u[0] is a different object, so u[0].save() just resaves exactly what’s in the database already, because it refreshes on u[0]. Unfortunately, QuerySet just doesn’t have any sort of “slice caching”, so everytime you use [] you need to cache it yourself by saving it to a seperate name (in the case of a list, eg [:3], you want to pass it through list() to run the query if you aren’t using a for loop). This should probably be better documented…

(I’ve been bitten by this myself… One example I’ve yet to fix is the random photo link on my frontpage: due to the order_by(’?') the random photo has an entirely different random alt tag and links to a further different random photo.)

]]> By: SmileyChris http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9509 SmileyChris Mon, 09 Apr 2007 22:31:33 +0000 http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9509 Saving a password isn't done inside of set_password so this is what happens: 1. >>> u[0].save_password('testme') 2. The user's details are retrieved from the database and a User instance is created. 3. The password is changed for this instance (but it hasn't been saved). 4. >>> u[0].save() 5. The user's details are retreived *again* from the database and a *new* User instance is created. 6. This new instance is saved (and since no data has changed for this second instance, you won't get your new password). Saving a password isn’t done inside of set_password so this is what happens:
1. >>> u[0].save_password(’testme’)
2. The user’s details are retrieved from the database and a User instance is created.
3. The password is changed for this instance (but it hasn’t been saved).
4. >>> u[0].save()
5. The user’s details are retreived *again* from the database and a *new* User instance is created.
6. This new instance is saved (and since no data has changed for this second instance, you won’t get your new password).

]]> By: amit http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9501 amit Mon, 09 Apr 2007 21:47:31 +0000 http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9501 SmileyChris: But shouldn't u[0].save() change the value in the database ? Infact, after executing the u[0].save() function, I did another User.objects.all() call and it still shows the old password. Gábor: watch the password attribute, it needs to change after save() function, but it did not change the first time, but changed when the save method is accessed via q reference. SmileyChris: But shouldn’t u[0].save() change the value in the database ? Infact, after executing the u[0].save() function, I did another User.objects.all() call and it still shows the old password.

Gábor: watch the password attribute, it needs to change after save() function, but it did not change the first time, but changed when the save method is accessed via q reference.

]]> By: Gábor Farkas http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9495 Gábor Farkas Mon, 09 Apr 2007 20:32:22 +0000 http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9495 hi, maybe i overlooked something, but i can't see any problem with the example you showed. could you perhaps explain the problem in more detail? hi,

maybe i overlooked something, but i can’t see any problem with the example you showed. could you perhaps explain the problem in more detail?

]]> By: SmileyChris http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9494 SmileyChris Mon, 09 Apr 2007 20:07:20 +0000 http://amit.chakradeo.net/2007/04/09/django-queryset-weirdness/#comment-9494 The problem here isn't queryset caching, but the fact that QuerySet objects use custom array slicing (http://www.djangoproject.com/documentation/db-api/#limiting-querysets). Every time you were doing u[0], you were getting the original object from the database again. The problem here isn’t queryset caching, but the fact that QuerySet objects use custom array slicing (http://www.djangoproject.com/documentation/db-api/#limiting-querysets). Every time you were doing u[0], you were getting the original object from the database again.

]]>