On 15 Sty, 05:33, James Bennett <ubernost...@gmail.com> wrote: > On Thu, Jan 14, 2010 at 10:26 PM, Kieran Brownlees <kbrownl...@gmail.com> > wrote: > > Basic example of format: > > Main Thread: print objects.all() > > Spawned Thread: print objects.all() -- same as main thread > > Main Thread: objects.create(newObj) > > Main Thread: print.objects.all() -- correct queryset, original + new > > Spawned Thread: print objects.all() -- only contains the original > > objects, not the new one? > > This would be the expected result with the default transaction > isolation of most databases, and has nothing to do with threading. >
To be more explicit - Python DB API spec states that connection should, by default, have autocommit turned on - which means that there is always an ongoing transaction at DB level. Now, for MySQL backend, which I'm most familiar with, default isolation level is REPEATABLE READ, which means that first access to given table freezes its state for the duration of current transaction. And because Django default behaviour is @autocommit, i.e. it doesn't issue any COMMIT/ROLLBACK statements for fetches, only for writes, all subsequent queries results in the same queryset (in terms of elements, not object id). -- Tomasz Zielinski http://pyconsultant.eu
-- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
