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
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
>
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
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
> 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.
> 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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
19 matches
Mail list logo