On 10/20/2014 12:26 PM, Carl Meyer wrote:
> On 10/19/2014 12:54 AM, Marc Tamlyn wrote:
>> I guess now with migrations we have a nice way of running the SQL
>> against the database to create the stored procedures.
>>
>> However if we plan to make this a public API, it should be a nice one.
>>
Hi Marc,
On 10/19/2014 12:54 AM, Marc Tamlyn wrote:
> I guess now with migrations we have a nice way of running the SQL
> against the database to create the stored procedures.
>
> However if we plan to make this a public API, it should be a nice one.
> Something along the lines of
Hi Wayne,
On 10/20/2014 04:59 AM, Wayne Ye wrote:
> Hi Carl,
> Thanks for the encouragement!
> I've created a new ticket in
> Trac: https://code.djangoproject.com/ticket/23689#ticket, could you
> please kindly take a look, feel free to revise it if I missed anything,
> and change the triage
Hi Carl,
Thanks for the encouragement!
I've created a new ticket in Trac:
https://code.djangoproject.com/ticket/23689#ticket, could you please kindly
take a look, feel free to revise it if I missed anything, and change the
triage status, thanks a lot!
I will try to submit a patch/pull request
HI Anshuman,
On Mon, Oct 20, 2014 at 2:03 PM, Anshuman Aggarwal <
anshuman.aggar...@gmail.com> 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):
>
>
>
>
>
>
> as
Wouldn't a manual transaction (suitably rolled back after a bunch of
changes) retain atomicity as well?
The proposed solution using the UPDATE FROM from_list ... syntax and
based on the postgres documentation link (below) does not seem to be any
inferior to doing a single UPDATE XYZ SET A =
No, it doesn't. The atomicity semantics of update() are impossible to
implement without it, this isn't the case for a multi-object UPDATE as far
as I can tell.
Alex
On Sun, Oct 19, 2014 at 11:34 PM, Anshuman Aggarwal <
anshuman.aggar...@gmail.com> wrote:
> Thanks for the input Javier. Wouldn't
Thanks for the input Javier. Wouldn't a similar argument hold for:
UPDATE books_book
SET
price = 10 where pk = 1, price = 25 where pk = 2 .
Such a single SQL statement would also have similar benefits to having much
less data to prepare, send and interpret vs having multiple update
On Mon, Oct 20, 2014 at 1:03 AM, Anshuman Aggarwal
wrote:
> 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 .update()...I am sure the performance of