On 2/28/06, ZebZiggle <[EMAIL PROTECTED]> wrote: > I agree that this problem is pretty fundamental. I don't know what > worries me more, the fact that the problem exists or the architects > don't see the problem.
I wouldn't put it that. It is a problem and things like transaction support do show up on TODO lists, but right now it is simply not the priority that you would like it to be. Keep in mind that Django encompasses a lot of uses and as has been pointed out, for the majority of uses (the majority of website types), non-"last-write-wins" transaction support is not a priority. Feel free to come up with your own solution and submit a patch if you'd like to get it done sooner, or just wait for the TODO items to move up in the priority list. > I think in my case I can isolate the offending code and use some form > of "double-buffering" technique to solve it. But, it's not going to be > pretty. I would again suggest you take a look at the magic-removal branch <http://code.djangoproject.com/wiki/RemovingTheMagic>. You could encapsulate such code in the actual save() call and fake the Django ORM having that support, and then when Django does provide something that you are happy with you can pull out your custom save() code and the rest of your code probably won't notice. You can even write your own object "Manager" to have fuller control of object caching and to implement said save()-overload code for several model classes. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
