id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
15748	QuerySet subscripting won't work as expected	zhutao.iscas@…	nobody	"when got a QuerySet by using filter and it's easy to use the following code to do the change and save operation:


{{{#!python
qs = SomeModel.objects.filter(owner_id=123)
# suppose qs has 1 or many elements
last_login_time = qs[0].last_login_time
qs[0].last_login_time = datetime.now()    # I expect it can assign the new value, but it won't
assertEquals(qs[0].last_login_time, old_login_time)   # YES, it doesn't change
qs[0].save()   #So it won't update the old record
}}}


And after figuring this out, the following code will be used instead and it works:


{{{#!python
qs = SomeModel.objects.filter(owner_id=123)
# suppose qs has 1 or many elements
obj = qs[0]
last_login_time = obj.last_login_time
obj.last_login_time = datetime.now()    # I expect it can assign the new value, but it will
assertNotEquals(obj.last_login_time, old_login_time)   # YES, it does change
obj.save()   #So it will update the old record as expected
}}}

And I have met some of my friends/colleagues use the first approach to do the record updating. And IMO, it's
natural and prone to use. (when you *type qs[0]* and *type obj* , they have the same ''type'')

After reading the code(db.models.query), it can be figured out why.(when you subscript the QuerySet it will use the  qs = self._clone() and assigning a value won't change at all) 

Possible solutions:

1. make the assigning work for the subscripting QuerySet
2. announce the above first approach is wrong and let the users know it

"	Bug	closed	Database layer (models, ORM)	1.2	Normal	invalid	QuerySet		Unreviewed	0	0	0	0	0	0