That does fix it - thanks Michael.
I just want to summarize what I'm seeing, though, in case it helps others:
- In no place, either in my MySQL shell or my Python Django session,
am I explicitly starting a transaction. Further, my MySQL shell has
auto_commit on.
- If I make a change in the MySQL shell, it isn't reflected by
getting a new QuerySet from the Django model.
- If, in the Python session, I call transaction.commit(), I get an
error saying that I'm not under transaction management.
- After calling transaction.commit() and getting that error, getting
a new QuerySet does reflect the new DB changes.
So that's a work-around that I can use, but...is it okay behavior? That
seems pretty broken. Is it possible that Django's DB connection has
auto-commit off, but explicitly calls COMMIT internally on save()
operations when there's no Django-level transaction in play?
Thanks again to everyone for all of your help - I was afraid that there
wouldn't be a workaround for this at all.
-Greg
Michael Radziej wrote:
> Hawkeye schrieb:
>> 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.
>
> I made a transaction.commit(), got the same error, but then the
> Foo.objects.all() returned the new set. I'm not sure why I get
> the error, but the behaviour is normal for certain transaction
> isolation levels. You don't see the result of transcations that
> committed after the start of your current transation (for
> 'repeatable read' and 'serializable')
>
> You can have the same fun with two mysql sessions and without any
> django.
>
> Try this (you might need to set transaction level repeatable read
> to make it work):
>
>
> Session1: begin;
> select * from xyz
>
>
> Session2: delete from xyz;
> Session2: commit;
>
> Session1: select * from xyz
>
> This is a normal database thing an not mysql specific, but
> there's a long but fine article on
>
> http://dev.mysql.com/books/mysqlpress/mysql-tutorial/ch10.html
>
>
> Michael
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
