Hey Russ, On Sat, 2009-03-14 at 14:10 +0900, Russell Keith-Magee wrote: > Hi all, > > [9967] introduced a failure into the test suite, highlighting either > an error in the documentation, or a potentially nasty problem that > requires fixing. > > According to the docs[1] : > > "The update() method is applied instantly and doesn't return anything" > > Except... it does. > > Further complicating matters: the value that is returned varies > slightly depending on the database. Postgres and SQLite return the > number of rows that were potentially affected - i.e., the number of > rows that match the selection criteria. MySQL, however, returns the > number of rows that are actually modified. This means that if no > columns are changed as a result of an update, a successful MySQL > update call will return a value different that returned by SQLite and > Postgres.
Aah .. I knew that one, once. I had completely forgotten about that. Wow.. deja vu. Thanks for working it out. :-) > > This is the cause of the failure introduced by [9967] - this changeset > introduces a test [2] to model_inheritance_regress that makes 2 > successive calls to update a model attribute to the same value - under > MySQL, the second call isn't a modification, so it returns 0, not 1. > > So - which one is correct? Documentation or implementation? And which > one can we change without violating backwards compatibility? The documentation is wrong here. I hadn't realised we even documented that, so I didn't check when I added that, way back when. We've been returning something from update() since before 1.0, so it's a docs bug, rather than a backwards-incompat change. The reasoning here is this: We need the update return value for Model.save(force_update=True). It's the only way to tell if a row was actually updated. An update query that alters zero rows still succeeds, but it is in wrong in that particular siutuation. The test in question, that is failing, could be converted into a failing force_update example, for example. We need to fix the MySQL handling there and work out how to tell if *any* rows are updated. Actually, that's what we really need there: a way to tell if any rows are updated. The actual number is pretty irrelevant for our purposes. So I'd be happy documenting that it returns True/False if we can get that indication out of the update. 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. [...] > However, I am also sensitive to the fact that someone might have a use > case for a return value coming from update(). Yeah, the guy who added it does. (hi there!) :-) 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 -~----------~----~----~----~------~----~------~--~---
