Re: cursor.callproc()

[Carl Meyer]

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.
>> Something along the lines of db.procedures.proc_name(*args, **kwargs)
>> would be preferable I think. Obviously this requires more magic to make
>> it work (or explicit registration of your procedures).
> 
> I know this is hypothetical, but I don't think that is a particularly
> nicer API, or that we should provide such syntactic sugar atop
> callproc(). Providing the procedure name as a string is not really a
> problem, and is preferable to doing `__getattr__` magic or requiring
> registration of procedures; the syntactic sugar just doesn't provide
> enough benefit to justify the magic, and all the various ways that that
> magic could confuse users and cause maintenance issues.

(I should clarify: I do think there are ways that we could improve on
the PEP 249 callproc() API if we were providing a higher-level
Django-specific alternative. I just don't think that moving the
procedure name from a string argument to a magical getattr-based Python
function is a good idea.)

Carl

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/5445548D.3020407%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: cursor.callproc()

[Carl Meyer]

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 db.procedures.proc_name(*args, **kwargs)
> would be preferable I think. Obviously this requires more magic to make
> it work (or explicit registration of your procedures).

I know this is hypothetical, but I don't think that is a particularly
nicer API, or that we should provide such syntactic sugar atop
callproc(). Providing the procedure name as a string is not really a
problem, and is preferable to doing `__getattr__` magic or requiring
registration of procedures; the syntactic sugar just doesn't provide
enough benefit to justify the magic, and all the various ways that that
magic could confuse users and cause maintenance issues.

Carl

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/544553EA.3000707%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django detects HTTP Accept-Language header in case-sensitive manner

[Carl Meyer]

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 status, thanks a lot!
> 
> I will try to submit a patch/pull request within few days.

Sorry for the confusion, I didn't communicate clearly.

Although I initially thought (based on inadequate code inspection) that
your report was accurate, Ramiro already corrected me in this thread
(and also Claude on the ticket you opened). Django does handle the HTTP
Accept-Language header case-insensitively (ever since [1]). If that's
not working for you, then something else is going on with your project.
Perhaps you are using an older Django version which pre-dates that commit?

The only remaining action item from this thread was to update the
documentation at [2] to clarify that Accept-Language is
case-insensitive. This is the piece I thought you were offering to write
a pull request for. I've now made this update myself (in [3]), so I
don't think there's anything left to be done here.

Thanks for your interest in contributing to Django!

Carl

 [1]
https://code.djangoproject.com/changeset/2bab9d6d9ea095c4bcaeede2df576708afd46291/
 [2] https://docs.djangoproject.com/en/dev/topics/i18n/#definitions
 [3]
https://github.com/django/django/commit/2118aa8aeafe0a215eae7188c40484d791921c67

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/54454E81.1050505%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django detects HTTP Accept-Language header in case-sensitive manner

[Wayne Ye]

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 within few days.

Sincerely yours,
Wayne

On Friday, October 17, 2014 11:48:34 PM UTC+8, Carl Meyer wrote:
>
> On 10/16/2014 09:41 PM, Wayne Ye wrote: 
> > HI Carl and Ramiro, 
> > Thank you both very much for tracking this issue! 
> > 
> > Actually I am a junior Django developer (but has nearly 10 years exp on 
> > ASP.NET and RoR), I am eager to contribute to the Django project!  If 
> > this issue has not yet been logged onto Trac and not yet working in 
> > progress, can I humbly request give me an opportunity to fix it, I will 
> > feel so honored and excited to be working on it. 
> > 
> > Looking forward to your reply, if you agree I will try to fix this 
> > within few days! 
>
> Sure, feel free to submit a pull request! 
>
> Carl 
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/2a130619-a15a-4696-86a2-da158fb52dac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

[Russell Keith-Magee]

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 opposed do:
> 
>
>  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 .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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

[Anshuman Aggarwal]

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 = 1, so it makes a valid
candidate for the ORM to expose it to applications which require the same.

http://www.postgresql.org/docs/9.3/static/sql-update.html

On 20 October 2014 12:06, Alex Gaynor  wrote:

> 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 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
>> queries being collated into a single transaction.
>>
>> On 20 October 2014 11:52, Javier Guerra Giraldez 
>> wrote:
>>
>>> 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 above
>>> > pseudo code would be about the same (or sufficiently small as to be
>>> > ignorable)...
>>>
>>>
>>> i'm sure it's far from ignorable.  .update() generates an UPDATE
>>> ... WHERE ... statement, not specifying each record to be updated,
>>> just the criteria to let the DB engine choose them.  Also, the new
>>> field content is either a constant or specified as a function of other
>>> fields (when using F() objects); again, not specified individually,
>>> but let to the DB engine to work it out.
>>>
>>> in sum, it's a _lot_ less data to prepare, send, and interpret and
>>> uses a heavily optimized, totally SQL statement.  Not having it would
>>> be a big missing feature.
>>>
>>> --
>>> Javier
>>>
>>> --
>>> 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
>>> django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> 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/CAFkDaoQi3z62emT4Dk1hAvpM5sSUshbFSoOqumA0kZymLURO9A%40mail.gmail.com
>>> .
>>> 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 django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> 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-d5daWgeOOBAOgTg9nWRhQnk%3DB_TvhpRTLPy2Sr-AqsiOxng%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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/CAFRnB2XvKC_oHKymGg5J05kQF9RgSmp0hWPVgpU6%2BbmiNZ-W%2BQ%40mail.gmail.com
> 

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

[Alex Gaynor]

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 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
> queries being collated into a single transaction.
>
> On 20 October 2014 11:52, Javier Guerra Giraldez 
> wrote:
>
>> 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 above
>> > pseudo code would be about the same (or sufficiently small as to be
>> > ignorable)...
>>
>>
>> i'm sure it's far from ignorable.  .update() generates an UPDATE
>> ... WHERE ... statement, not specifying each record to be updated,
>> just the criteria to let the DB engine choose them.  Also, the new
>> field content is either a constant or specified as a function of other
>> fields (when using F() objects); again, not specified individually,
>> but let to the DB engine to work it out.
>>
>> in sum, it's a _lot_ less data to prepare, send, and interpret and
>> uses a heavily optimized, totally SQL statement.  Not having it would
>> be a big missing feature.
>>
>> --
>> Javier
>>
>> --
>> 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
>> django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> 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/CAFkDaoQi3z62emT4Dk1hAvpM5sSUshbFSoOqumA0kZymLURO9A%40mail.gmail.com
>> .
>> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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-d5daWgeOOBAOgTg9nWRhQnk%3DB_TvhpRTLPy2Sr-AqsiOxng%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAFRnB2XvKC_oHKymGg5J05kQF9RgSmp0hWPVgpU6%2BbmiNZ-W%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

[Anshuman Aggarwal]

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 queries
being collated into a single transaction.

On 20 October 2014 11:52, Javier Guerra Giraldez  wrote:

> 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 above
> > pseudo code would be about the same (or sufficiently small as to be
> > ignorable)...
>
>
> i'm sure it's far from ignorable.  .update() generates an UPDATE
> ... WHERE ... statement, not specifying each record to be updated,
> just the criteria to let the DB engine choose them.  Also, the new
> field content is either a constant or specified as a function of other
> fields (when using F() objects); again, not specified individually,
> but let to the DB engine to work it out.
>
> in sum, it's a _lot_ less data to prepare, send, and interpret and
> uses a heavily optimized, totally SQL statement.  Not having it would
> be a big missing feature.
>
> --
> Javier
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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/CAFkDaoQi3z62emT4Dk1hAvpM5sSUshbFSoOqumA0kZymLURO9A%40mail.gmail.com
> .
> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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-d5daWgeOOBAOgTg9nWRhQnk%3DB_TvhpRTLPy2Sr-AqsiOxng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

[Javier Guerra Giraldez]

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 above
> pseudo code would be about the same (or sufficiently small as to be
> ignorable)...


i'm sure it's far from ignorable.  .update() generates an UPDATE
... WHERE ... statement, not specifying each record to be updated,
just the criteria to let the DB engine choose them.  Also, the new
field content is either a constant or specified as a function of other
fields (when using F() objects); again, not specified individually,
but let to the DB engine to work it out.

in sum, it's a _lot_ less data to prepare, send, and interpret and
uses a heavily optimized, totally SQL statement.  Not having it would
be a big missing feature.

-- 
Javier

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAFkDaoQi3z62emT4Dk1hAvpM5sSUshbFSoOqumA0kZymLURO9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.