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 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've considered SqlObjects, but then I would perhaps just cut over to > TurboGears. A colleague has recommended SqlAlchemy. I'll look at both.
Max did a good job (in his e-mail) of explaining our thoughts on this. We don't implement this level of super object-instance consistency at this point because we aim for an 80% solution. The vast majority of Web sites don't require it. With that said, I think it would be a fantastic improvement to Django's database layer. You could solve it in the interim by creating a "status" field on your model, override save() so that it checks the status field against the status field of the newest object in the database, and throw an exception if the numbers aren't in sync. We could roll this into Django proper in a generic way if there's a demand. Alternatively, SQLAlchemy solves this problem by implementing an identity map, which is quite cool. You should be able to use SQLAlchemy with the rest of Django with no problems at all -- the only thing you won't be able to take advantage of is the admin framework. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
