"That's good to know, but as you have stated previously, transactions alone won't solve this problem. There still needs to be some concept of versioning on top of the transactions, which isn't trivial (arguably/perhaps even harder to do right than supporting transaction wrappers).
Perhaps we need another trouble ticket for versioning? " Aren't you just talking about the problem that one user may modify a record while a different user is editing that record at the same time, and the user editing the record will not automatically see the changes that were committed by the first user? If so, then this is not a problem unique to Django. This is how web development -- and any sort of n-tier application development -- works. These are stateless apps where the clients maintain no connection to the server. How do you expect a web app to be immediately updated with changes on server without continually polling the server for a refresh? And do you know what kind of hit on scalability that's going to have? Thousands and thousands of heavily used web apps are being used without this automatic refresh that you're talking about. It's a design constraint that app designers work with, in part because it's not a big deal and in part because it would be a big drag on scalability to provide that sort of auto-refresh. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
