Re: contrib.sessions test oddities

We figured out the phenomenon that triggered this problem: The djangobb middleware was saving items to the cache using integers (user ids) as the key and True as the value. Obviously this is an abhorrent practice in its own right both for disambiguation and security. We have submitted a patch

Re: deprecation vs removal

On Oct 1, 9:10 am, Luke Plant wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is  deprecated" or "has been deprecated", when what they mean is "will >

Re: contrib.sessions test oddities

Hi, It sounds like you're looking at tests for django.contrib.sessions.backends.cached_db. If that is the case, then it's not unusual that you would end up calling the LocMem cache backend. The cached_db session backend does all of its reads from the cache, only falling back to the database

contrib.sessions test oddities

I posted this message on -users today, but at PaulM's urging, I'm bringing it over here out of concern that it may reflect a bug in the contrib.sessions test suite. Here's the original message from -users (some -dev only notes follow) : I am having a problem with

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

> I was thinking of adding a recaptcha implementation, based on the work > of others, if that would work with licenses. But probably that choice > would indeed introduce an external (unwanted) dependency. Yeah... it's really a tricky problem. That solution is probably best as an external app.

Re: Handling admin media paths in the transition from 1.3 to 1.4

> I think that's not a dilemma at all, Django 1.3 requires setting > ADMIN_MEDIA_PREFIX to an appropriate value as before. No, that's exactly why this is a problem. Django 1.3 doesn't require setting ADMIN_MEDIA_PREFIX in the local settings, because it has a default value that works for most

Re: Django sprint in North Carolina, Nov. 12-13, 2011

On Tue, Oct 4, 2011 at 2:57 PM, Tobias McNulty wrote: > We'd like to host another Django sprint here at Caktus the weekend of > November 12 and 13, 2011. Hooray! Thanks for taking the initiative and getting this rolling. If you need any help (financial or otherwise) from

Django sprint in North Carolina, Nov. 12-13, 2011

Hi All, We'd like to host another Django sprint here at Caktus the weekend of November 12 and 13, 2011. A development sprint is an excuse to get together, write some code, and have a good time doing it. The purpose of this sprint will be to help finish features and push out bug fixes in

Re: Patch for using custom managers in a reverse relation. (#3871)

Well, this is useful in the case where you have multiple custom managers defined on a model and you need to a select a specific manager. Doing so, common filter operations that are long expressions or are quite complicated, need not be repeated every time. On Oct 4, 9:40 am, Tai Lee

Re: ILIKE vs. LIKE LOWER() for PostgreSQL

On 4 Oct 2011, at 9:19 AM, Jonas H. wrote: > On 10/04/2011 05:51 PM, Ted Gruenloh wrote: >> The django online documentation mentions that the SQL equivalent for >> __icontains is something like: >> >> SELECT ... WHERE headline ILIKE '%Lennon%'; >> However, for postgresql - one of the dbs

UPPER vs. ILIKE for __icontains

Jonas: Thanks for the response.  The ticket you referenced refers to __iexact.   In that case, I agree with the use of UPPER.  My question/suggestion is about __icontains, which must either use '...LIKE UPPER()' or ILIKE.  In my quick tests, ILIKE wins by about 10% on a table with 1 million

Re:

On 10/04/2011 05:51 PM, Ted Gruenloh wrote: The django online documentation mentions that the SQL equivalent for __icontains is something like: SELECT ... WHERE headline ILIKE '%Lennon%'; However, for postgresql - one of the dbs that actually supports ILIKE - I noticed __icontains was

[no subject]

All: I'm not a Django developer, nor will I pretend to be.  But I did come across something I thought you should be aware of. The django online documentation mentions that the SQL equivalent for  __icontains is something like:     SELECT ... WHERE headline ILIKE '%Lennon%'; However, for

Re: Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

On Tue, Oct 4, 2011 at 4:35 AM, Johannes Dollinger wrote: > as you could write Q(foo=Q(...)) instead of Q(..).push('foo') I thought that would work magically, since the Q object would just pass that to the filter(); but a quick test proved me wrong. I've just refactored

Re: Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

On Tue, Oct 4, 2011 at 4:35 AM, Johannes Dollinger wrote: > Thanks for starting this! > Why did you chose a staticmethod instead of an instancemethod? because it's applied recursively not just to tree.Node, but to the children and all members. it would be cleaner as a

Re: Handling admin media paths in the transition from 1.3 to 1.4

Aramgutang, > Currently, it is unclear as to how apps that override admin templates > should maintain compatibility with both 1.3 and 1.4 when referring to > the admin media file URLs in the overridden templates. This applies > primarily to third-party apps like django-admin-tools, that want to >

Re: Feature proposal: Q.push(...) and QuerySet.filter(relfield=Q(...))

Am 03.10.2011 um 20:01 schrieb Javier Guerra Giraldez: > On Fri, Sep 30, 2011 at 4:37 PM, Johannes Dollinger > wrote: >> The aim of this proposal is to reuse Q objects for models that are related >> through FK or M2M fields. > > i really want to have this feature! so

Re: deprecation vs removal

On 04/10/11 05:56, Tai Lee wrote: > > > On Oct 4, 11:17 am, Russell Keith-Magee > wrote: >> I'm completely agreed that the 'soft' deprecation is useful. I'm just >> complaining about the ambiguity in the language: "We're deprecating >> this feature by marking it

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

Hi Paul, Thanks for your review and remarks. I will think on it more, and will write a longer response later. For the moment just this quick reponse: I was thinking of adding a recaptcha implementation, based on the work of others, if that would work with licenses. But probably that choice