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)...
the ORM is much about convenience and this additonal syntax seems to
provide the same, without taking away much.
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.
Regards,
Anshu
On 20 October 2014 11:16, Russell Keith-Magee <[email protected]>
wrote:
> Hi Anshuman,
>
> As I mentioned when you raised this issue 2 days, ago:
>
>
> https://groups.google.com/d/msgid/django-developers/bac70fe2-3bbb-45c9-b805-5469e89f2754%40googlegroups.com?utm_medium=email&utm_source=footer
>
> if you can provided evidence to back up your claim, I'll reverse my
> position on the need for an API entry point like the one you describe.
>
> However, as I said in that thread, the comparison shouldn't be "Update
> 1000 rows in 1 statement" vs "Update 1000 rows using 100 transactions" - it
> should be vs "update 1000 rows in a *single* transaction". Using 1000
> *transactions* will clearly be slower, but my gut tells me that 1000
> individual SQL statements, amalgamated into a single transaction, should be
> just as efficient as a single large statement - or, at least, that the
> difference in performance will be sufficiently small as to be ignorable.
>
> You're not going to advance your cause by starting a new thread every
> couple of days until someone agrees with you. I've given you a specific
> course of action - provide performance benchmarks. Until you provide them,
> the only thing reposting like this will do is annoy the people you need to
> help you.
>
> Yours,
> Russ Magee %-)
>
> On Mon, Oct 20, 2014 at 1:22 PM, Anshuman Aggarwal <
> [email protected]> wrote:
>
>> Posting this Django Project ticket that I opened to track the enhancement
>> request to update multiple rows with different values for the same field
>> for a particular Django queryset in a single SQL query without having to
>> write raw SQL. Please see the discussion there.
>>
>> https://code.djangoproject.com/ticket/23646
>>
>> I disagree with Russel that there will not be a performance impact.
>> Firing 1000s of SQL queries to update single rows will lead to locking of
>> the table in Postgres atleast, not to mention the overheads of individual
>> SQL queries, transactions etc. If the database support natively updating
>> multiple values then it can be done that way.
>>
>>
>> A possible SQL solution is outlined in the link (below) but it should
>> ideally be supported via the Django Manager and not via a Raw SQL which
>> becomes much harder to maintain.
>>
>> http://stackoverflow.com/questions/18797608/update-multiple-rows-in-same-query-using-postgresql
>>
>> If agreed, I would look to contributing a patch if we can finalize the
>> API for the same here.
>>
>> Thanks,
>> Anshuman
>>
>> --
>> 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/c650999b-7a0d-49e8-aa0d-84e789b2f833%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/c650999b-7a0d-49e8-aa0d-84e789b2f833%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/Hcsh4r9_mHg/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAJxq84-ZRUqgoCrdH9ORU5gxhD4WMSU64orrw9nfKwfkzXDGYg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAJxq84-ZRUqgoCrdH9ORU5gxhD4WMSU64orrw9nfKwfkzXDGYg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAK-d5dagArA%2BkicQ74RFgS90Z%2BujGX0_TCLRp8NcQmEHu%3DSc-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
