I had the same reaction at first... "this has to be a transaction
issue", but I decided to give it a try.
I'm working from trunk, and here's what I did to recreate the problem:
==========
{{ In manage.py shell }}
>>> a = Foo.objects.all()
>>> a
[< Foo: Foo 5>, < Foo: Foo 6>, < Foo: Foo 7>, < Foo: Foo 8>]
{{ In MySQL shell }}
delete from foo_foo where id=8;
commit;
exit;
{{ In same manage.py shell }}
>>> a
[< Foo: Foo 5>, < Foo: Foo 6>, < Foo: Foo 7>, < Foo: Foo 8>]
>>> b = Foo.objects.all()
>>> b
[< Foo: Foo 5>, < Foo: Foo 6>, < Foo: Foo 7>, < Foo: Foo 8>]
>>> transaction.rollback()
Traceback (most recent call last):
File "<console>", line 1, in ?
File "[...]/django/db/transaction.py", line 161, in rollback
set_clean()
File "[...]/django/db/transaction.py", line 102, in set_clean
raise TransactionManagementError("This code isn't under transaction
management")
TransactionManagementError: This code isn't under transaction
management
>>> b[3]
< Foo: Foo 8>
==========
Maybe we're making the same mistake, but this behavior seems strange to
me as well.
--Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
