Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Eduardo, On 04/26/2011 02:47 PM, legutierr wrote: >> With your proposed change, if I happen to have a FavoriteBirthdayPresent >> in the database for a given year with an empty "username" field, it >> would incorrectly prevent any user from creating their own >> FavoriteBirthdayPresent for that

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Carl- > With your proposed change, if I happen to have a FavoriteBirthdayPresent > in the database for a given year with an empty "username" field, it > would incorrectly prevent any user from creating their own > FavoriteBirthdayPresent for that year. > > I'll readily admit that's a corner

Odp: Re: Odp: Re: Storing language in session/cookie

I don't see any good reason to store the language in session rather than cookie. And storing it in cookie has major advantage, that is avoiding creating unnnecessary sessions. I say if LocaleMiddleware is in our way to better behavior, let's just change it. But I understand that revolution is

Re: Odp: Re: Storing language in session/cookie

Well we are actually not trying to address the issue on ticket #13217 I think. We are addressing the way language gets stored for the client. Because LocaleMiddleware checks for a session anyway. If it was decided wontfix then doing it the way I supposed should be OK I think. If I'm mistaken -

Re: Odp: Re: Storing language in session/cookie

On 26/04/11 14:21, Madis wrote: > Well I think there is no need for another setting and I think there is > no problem setting the lang twice - as then the cookie is not always > accessed as it first checks for the language in the session. It only > looks for it in the cookie if there is no session

Re: Odp: Re: Storing language in session/cookie

There is also a ticket here which proposes a patch - http://code.djangoproject.com/ticket/14825 I used it last night - it also works but wont give the users the freedom to choose if they want to set the lang cookie or not and also adds overhead. -- You received this message because you are

Re: Odp: Re: Storing language in session/cookie

Well I think there is no need for another setting and I think there is no problem setting the lang twice - as then the cookie is not always accessed as it first checks for the language in the session. It only looks for it in the cookie if there is no session or the customer is returning to the

Re: Help review tickets, get a prize!

On Thu, Apr 21, 2011 at 04:31, Jacob Kaplan-Moss wrote: > On Wed, Apr 20, 2011 at 5:44 PM, Carl Meyer wrote: > > So you don't necessarily reproduce it yourself before marking Accepted? > > Mm, it depends. Sometimes I don't need to -- it's clearly a bug, and

Odp: Re: Storing language in session/cookie

As lukeplant commented on a ticket: This is proposing the same thing as #12794, but for a different reason. #13217 is related, but the solution proposed here was not proposed there, and doesn't have the

Odp: Re: Storing language in session/cookie

I've created a ticket: http://code.djangoproject.com/ticket/15902 I agree with Madis. Having a setting to choose where the current language is stored would be convenient and also backwards compatible. How do you think the setting should look like? I propose: LANGUAGE_FORCE_COOKIE ...which

Re: sitemaps and prepend_www

Usually you would create a ticket on trac [1] which describes your problem and reasoning. And you can attach a patch file to it. This way, it will go through the normal triaging and feature requests. [1] http://code.djangoproject.com/newticket -- Gert Mobile: +32 498725202 Twitter: @gvangool

A coupla patch reviews

Hi there, I've just posted a patch for #14262 to add a new assignment_tag helper function. Is anyone keen to review it? Also, it would be great if someone could review the latest patch for #15805. If that one gets checked in then we'll also be able to fix #14608 and then I'll start work on