On 10/30/07, Peter <[EMAIL PROTECTED]> wrote: > > This worked in the trivial case of one user in the django python > shell. > > However, when I tried to load a page that tried to read the table - > while it was still write locked - the page was not returning (as I > would expect), so I unlocked the tables from within the python shell > and then I received an OperationalError suggesting that the browser > view had screwed up locks (even though there was nothing in the view > code that called the locking methods - maybe this was middleware?) -- > "Table '<table_name>' was not locked with LOCK TABLES"
I find this paragraph very confusing -- surely the view code did call the locking method, else why would you have expected the browser view to block until you released the locks in the shell? Anyway, my guess is you are running afoul of this, from the MySQL docs ( http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html): When you use LOCK TABLES, you must lock all tables that you are going to use in your statements. While the locks obtained with a LOCK TABLES statement are in effect, you cannot access any tables that were not locked by the statement. If you try to access a table you have not locked, you will get an OperationalError naming the table you have tried to access and stating that it was not locked with LOCK TABLES. Perhaps select_related() or something is pulling in a join on a table you weren't expecting? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
