HI Anshuman, On Mon, Oct 20, 2014 at 2:03 PM, Anshuman Aggarwal < [email protected]> wrote:
> Hi Russ, > Notwithstanding the performance, the current solution of doing 1000 > updates in a single transaction using ORM appears to be (in pseudocode > below): > > <start manual transaction> > <Loop through all update values> > <Issue individual django update statement> > <end manual transaction> > > as opposed do: > <Issues multiple value update statement in a single line> > > My point is if this is acceptable then why have a .update() in ORM. I am > sure by manually collating the updates in a single transaction that could > also be done equally well. > > The idea of having a .update() ORM construct is to be able to do this > without having to fall down to a manual transaction every time, otherwise > why have a DB level <qs>.update()...I am sure the performance of above > pseudo code would be about the same (or sufficiently small as to be > ignorable)... > Because: 1) a single UPDATE statement isn't the same as "get and save". Get and save requires *at least* 2 SQL queries, *and* a transaction wrapping them. 2) Even if this wasn't true, Update is a sufficiently common task that it warrants first class API representation. I'd argue that bulk update (of the kind you describe) isn't. 3) There are certain classes of update (e.g., "increment current value by one") that benefit from being expressed as a single statement. the ORM is much about convenience and this additonal syntax seems to > provide the same, without taking away much. > But it *does* take away. Complexity is a cost. The sort of API you've described will either make the API for update() more complex, or it will require a *new* API entry point (e.g., bulk_update(), or similar). And it adds new complexity to the implementation, since there's now a whole new update statement implementation path that needs to be maintained. At some point, we have to make a decision over what we include, and what we exclude. I'm putting it to you that unless there's a *significant* performance benefit associated with bulk updates, then it's not worth the complexity to add this new API entry point. As for the "need" for this API - well... Django has been around for almost 10 years; at this point, if there was a pressing need for bulk updates, we would be aware of them. No intention to annoy and thanks for looking into it, but I've only raise a > ticket, and started the discussion on the users/dev group as you had > suggested. > My point was that you've started this conversation 3 times now. The first time was a misunderstanding about the right mailing list. I pointed you in the right direction, and you followed that direction. You did the right thing. The second time you posted the right information in the right mailing list, and I responded with a request for a specific course of action. So far, you haven't provided any indication that you're planning to follow up on that course of action. The third time was this thread - a repeat of *exactly* the same information in the second post, without *any* of the information that was requested of you in the second thread. *That* is the source of my "annoyance". Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq8484XHc6BrAwy0Urg1ZChUsbH3SAduHp0Gf7Kz2R5UAnEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
