>Of *course* you'd expect that obj2.data != obj1.data -- Django's not >going to be able to hide the fact that you're using a database from you >(nor should it).
Think distributed: two requests updating the same data concurrently. Last write wins. Data might not be what you expect, as you can't make sure that you have the version you directly read before updating. This is the simple scenario. Often this doesn't matter, as "last write wins" is quite acceptable. But sometimes - for example if you do financial transactions or shop stuff - this might be quite undesirable. But even then it might not hit you, as this is a solely update-related problem - it won't happen with inserts, as you usually have automatically generated id's and so concurrent inserts will get separate id's. And it can't be really solved without transactions, as you would need to be able to make sure that your fetched object is still the correct version that's in the database. Think for example about something like this: account = banking.get_account(pk=4711) ... do some calculation on what to store in the account account.amount += result_of_calcuation ... do maybe some more calculations for other stuff account.save() You can't be sure that your account still has the same amount when you do the += and the save is done, so you can't make sure that you don't stomp on updates others have already done in between. And just "move the read/update/save calls into one spot in the code" won't cut it - it would just make it less probable to hit this problem, but given a high enough update rate you will still hit it. Actually I had exactly that problem in a small project where I used the Django ORM out of laziness and did hit exactly this - I was collecting sum data on object values in a cumulative table. Of course I switched that to a simple SQL trigger mechanism, as it wasn't much more than just a python-written triggern (it was actually a _post_save code on the detail object that kept tallies of object kinds on the collection object). The SQL trigger was executed in the same transaction as the update SQL and so the problem was solved. But the account/amount problem above can't be solved on SQL level alone - it's fully application code depending and so you are currently fubar. At least unless we get transactions ;-) Granted, in most content-oriented and presentation-oriented applications you don't hit this problem - I did hit it because the relevant application needed a fast overview of data in the catalog and the items themselves where too many to count them on view time, so I needed the tallies. Other content and presentation oriented sites aren't that update-heavy to start with, and if they are, it's mostly people updating different parts of the database (and if two update the same thing, "last write wins" is the expected outcome anyway). So this is more a problem for people who do more processing-oriented sites. bye, Georg --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
