Re: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note

Exactly... I guess I was just asking for someone to say 'Don't use this if you think it will make the update any faster on Postgres' in the docs... in addition to what you just said :) On Fri, Nov 2, 2012 at 7:45 PM, Donald Stufft wrote: > The major help is preventing

Re: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note

The major help is preventing clobbering a value for concurrency. Prior to this when you loaded an object from SQL into a django model, it would fetch all the values as they were at that time, and store them in the model instance. Then when you saved it it would write all those values back out

1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note

I was just writing some code against 1.5 and thought I might use the new .save(update_fields=['xyz']) then I realized I was using PostgreSQL - which is an MVCC... which re-writes the entire row as far as I know even when one column is being updated. I popped into the release notes and it does

Re: Updating default errors in contrib.auth.forms.PasswordResetForm

The canonical way of handling this so as not to leak information like that is to do exactly the same thing UX wise for success and failures, and just update the message to state that if an email address by that account has been registered they will get an email soon. On Friday, November 2,

Re: Possible deprecation of depth= in select_related

On Fri, Nov 2, 2012 at 10:33 PM, Jacob Kaplan-Moss wrote: > On Fri, Nov 2, 2012 at 9:29 AM, Marc Tamlyn wrote: > > If anyone has any major objections to the deprecation of depth, you > should > > shout now. If there are no objections and people think

Re: Updating default errors in contrib.auth.forms.PasswordResetForm

Hi Lee, What you propose certainly sounds reasonable -- anything that reduces the exposure of valid accounts to an external source is a good thing, IMHO. Did you have an alternative wording to suggest? If you do, please open a ticket. Yours, Russ Magee %-) On Fri, Nov 2, 2012 at 9:42 PM, Lee

#16779 - a tutorial for first time Django contributors

Taavi Taijala has written a tutorial for new contributors that I've given an initial review. I'm hoping we can get a few more sets of eyes on it. Might be useful to pass it on to any newbies you know and have them try it out as well. Thanks! https://code.djangoproject.com/ticket/16779 --

Re: Github tags

Hi, They are (now) all there and signed with the release key: https://github.com/django/django/tags -- Please tell us if we missed something! Thx, Florian On Friday, November 2, 2012 5:17:25 AM UTC+1, Samus_ wrote: > > hi, I think that's great :) in the meantime could you please indicate the

Re: Possible deprecation of depth= in select_related

On Fri, Nov 2, 2012 at 9:29 AM, Marc Tamlyn wrote: > If anyone has any major objections to the deprecation of depth, you should > shout now. If there are no objections and people think it's ok to push this > deprecation in now, then I'll get a patch done on Monday. No

Possible deprecation of depth= in select_related

Hi all, The issue #16855 [1] tracks some unexpected behaviour in the chaining of `Queryset.select_related`. It's been proving rather complex to get a patch for this which works, mainly because of the complexity added by the depth argument. It has been proposed (by Luke Plant) that depth be

Updating default errors in contrib.auth.forms.PasswordResetForm

Hi all, I wasn't sure if it was best to open a ticket or post to the dev group so here I am... I was curious what others thought about changing the default error in the PasswordResetForm which currently displays "That e-mail address doesn't have an associated user account. Are you sure you've