On Sat, 2009-03-14 at 16:36 +1100, Malcolm Tredinnick wrote: [...] > > I understand what you're saying here, though, so it might not be easy. > I'll think about it a bit, but I'd like to make that return value > meaningful on all backends.
Just about to run out the door and I'll be offline until tomorrow, but I wanted to throw out this idea: I'd be happy saying "wontfix" for now on MySQL and we can conditionally avoid that test there. This is solved by adding "work out which columns changed" support to models, which I was intending to look at in the 1.2 timeframe. I might make time to bump that up to 1.1 (or we just say it's a known issue in 1.1 and will be fixed thereafter). Once we have that, if no columns have changed, force_update doesn't necessarily have to do anything (it's not quite that clear, but that's the idea -- see below), so we're fine and if it does have to do something, MySQL shouldn't return zero rows changed, so we have error detection back again. So a do nothing approach is survivable here for now. But, again, I'll keep thinking. Note: one reason this problem is potentially tricky is because it can only be optional behaviour. There's a time-race involved: load Model A, data changes, try to save Model A unchanged and it should reset the data, but won't because it looks like nothing has changed. So we can't turn it on unconditionally as some use-cases will fail because of it. I don't want to turn this thread into an incremental update thread, but that's why this is something that's still open. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
