On Sat, Apr 25, 2009 at 5:07 AM, Aaron Lee <waifun...@gmail.com> wrote:
> Today I just stumble upon a very strange bug and I am not sure if that's > Django bug or not. > > Here's the context: > I have a model Job which has a status field. > > For debugging, I run python manage.py shell and do > > jobs = Job.objects.filter(status__in=['A']) > > *I am using MySQL 5.0 InnoDb* > > Re-running this command will NOT get updated result even if a new job with > status 'A' is inserted to the DB (I explicitly turned off buffer_pool cache > and no query cache) > I then open another terminal and do python manage.py shell and run this > command and I got the newly updated result set. > This is due to InnoDB's default transaction isolation level of "repeatable read" combined with Django's default autocommit behavior that does not "commit" queries. So your manage.py shell is running in a single transaction that is not committed until you do some sort of update from it, meaning (in the absence of any update) that all queries will return whatever they returned the first time you ran them. See this thread: http://groups.google.com/group/django-users/browse_thread/thread/e25cec400598c06d for details on how to change either the transaction isolation level or the connection's autocommit setting to allow a query-only script/shell to see updates made by a different transaction. Karen --~--~---------~--~----~------------~-------~--~----~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
