I don't think that transactions are enough to solve this problem, but I could be wrong.
My understanding of a transaction is that it will prevent a write after a write, but not a read after a read... so if both read before either writes, the data will be incorrect. The data might also come from a cache, but the underlying issue is that the data is removed from the database before being returned. PLEASE CORRECT ME IF I'M WRONG. ==== example ==== A starts transaction, A reads 0, A writes 1, A ends transaction, B starts transaction, B reads 1, C starts transaction, C reads 1, C writes 2, C ends transaction, B writes 2, B ends transaction ==== /example ==== In tutorial 4's commentary, a similar problem was addressed, and Adrian's solution was to 'create a custom method on your model that does an "UPDATE polls_choices SET votes = votes + 1 WHERE id = %s".' I'm not quite sure how to make this happen... I didn't see any place to specify raw SQL to pass to the DB except for the SELECT statements that define a QuerySet (that doesn't mean they're not there). How does one specify raw SQL outside of a QuerySet? As an aside, this seems like a common design pattern... so maybe a .increment() method for 'IntegerField's would make sense. Thanks! --Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
