Hi, Well that's what I'm saying. It doesn't make any sense. By default, django runs the select_for_update query on the 'for read' database instead of running it on the 'for write' database.
In order to make my code not to break, I need to explicitly tell django that I want the query to run on the 'for write' database. => I need to write: pages = Page.objects.select_for_update().using(router.db_for_write(Page)).all() instead of just pages = Page.objects.select_for_update().all() If I don't add the 'using(router.db_for_write(Page)' I get the traceback mentioned in my initial message. Regards, Alex On Tuesday, February 19, 2013 9:23:29 PM UTC+2, Shai Berger wrote: > > Hi, > > On Monday 18 February 2013, Ioan Alexandru Cucu wrote: > > > > If I'm running a select_for_update statement in a multidb environment > that > > uses a read-only slave database > > > Why does this operation make sense? > > Why would you select-for-update if you don't intend to update? Or does > updating on a read-only slave somehow make sense? > > Thanks, > Shai. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
