Firstly thank you, secondly, how to get around it? I assume I need to force a commit for the transaction my thread is using, but querysets don't appear to have a documented method to do that.
Thank you On Jan 16, 1:52 am, Tomasz Zieliński <tomasz.zielin...@pyconsultant.eu> wrote: > 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 Zielinskihttp://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.
