In accordance with our security policy[1], a set of releases is being
issued tonight to fix a security vulnerability reported to the Django
project. This message contains a description of the vulnerability, a
description of the changes made to fix it, pointers to the the
relevant patches for each
I logged the issue here:
http://code.djangoproject.com/ticket/7233
and uploaded a test case.
mike
Jeremy Dunck wrote:
> On Tue, May 13, 2008 at 10:24 PM, Mike Chambers <[EMAIL PROTECTED]> wrote:
> ...
>> request.session['form_post_data'] = request.POST.copy()
>> request.session['foo'] = "bar"
I can't tell you how grateful I am that you posted this workaround,
Barry! Just in time for a site launch.
Like you said, I wonder if the multiple calls to to_tsquery() are
acceptable or if there's a more graceful solution here for the long-
term.
On May 13, 9:01 pm, Barry Pederson <[EMAIL PRO
Nightly build from subversion.
Ill put together a simple test. When posting a test, should I post an
entire project, or just the relevant parts?
mike
Jeremy Dunck wrote:
> On Tue, May 13, 2008 at 10:24 PM, Mike Chambers <[EMAIL PROTECTED]> wrote:
> ...
>> request.session['form_post_data'] =
Dave Lowe wrote:
> It worked prior to qsrf-merge. I have tried adding the quotes though,
> without success.
>
> On May 13, 9:59 am, David Cramer <[EMAIL PROTECTED]> wrote:
>> The database engine usually can't fill that in anyways, you should
>> probably quote it yourself (correct me if I'm wrong)
On Tue, May 13, 2008 at 10:24 PM, Mike Chambers <[EMAIL PROTECTED]> wrote:
...
> request.session['form_post_data'] = request.POST.copy()
> request.session['foo'] = "bar"
>
> Then, in another request:
>
> print request.session.keys()
> prints []
>
Definitely sounds like a bug.
What revision of Dj
I have been trying to track down and issue, and I think I may have
discovered a bug. However, before I log it, I wanted to post here and
ask what the expected behavior is.
I am using a pretty recent build.
The issue is that it appears trying to store a QueryDict (request.POST,
or a copy of a
> I ran the tests that come with django trunk and
> there are 4 failures, is this known?
>
Actually 5:
4 in regressiontests.defaultfilters.tests and 1 in
regressiontests.templates.tests...
I was about to post the same thing.
Regards,
Nicolas
--~--~-~--~~~---~--~--
It seems like, the problem is that on deserialization, the child object does
not get 'id' set, instead it has a field called 'parent_id' that is set.
If the 'id' were to be set, everything works fine, I assume that this means
that parent_id is not being handled correctly in save()? If id was set to
Im not suggestung to replace the sql use just that they are identical in
abstraction, and if the api truly doesn't want an sql feel, then it shouldn't
have one
-Original Message-
From: Sander Steffann <[EMAIL PROTECTED]>
Sent: Tuesday, May 13, 2008 1:03 PM
To: django-developers@googlegr
Hi,
> DISTINCT and GROUP BY are both annotating the results. Taking many
> rows, and turning them into a single row based on a key. DISTINCT would
> be the same as GROUP BY every, field, in, the, select.
Mathematically true, but I think having two separate concepts makes the code
easier to read
David Cramer said the following:
> DISTINCT and GROUP BY are both annotating the results. Taking many rows,
> and turning them into a single row based on a key. DISTINCT would be the
> same as GROUP BY every, field, in, the, select.
But forcing people to group by every field they select in orde
Hi, David,
even if annotate() actually _could_ replace distinct()... Wouldn't you
like to keep the syntactic sugar around? not to mention the backward
compatibility... Also, for users looking for the simple distinct
behaviour, it is very complex and unnecessary having to think of it in
terms of gr
It worked prior to qsrf-merge. I have tried adding the quotes though,
without success.
On May 13, 9:59 am, David Cramer <[EMAIL PROTECTED]> wrote:
> The database engine usually can't fill that in anyways, you should
> probably quote it yourself (correct me if I'm wrong).
>
> On May 13, 9:15 am, D
DISTINCT and GROUP BY are both annotating the results. Taking many rows, and
turning them into a single row based on a key. DISTINCT would be the same as
GROUP BY every, field, in, the, select.
On Tue, May 13, 2008 at 10:29 AM, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> David Cramer said the fol
David Cramer said the following:
> If that is the case, then annotate would replace GROUP BY, and should
> also be able to replace distinct().
Why would replacing distinct() ever make any sense?
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message bec
The database engine usually can't fill that in anyways, you should
probably quote it yourself (correct me if I'm wrong).
On May 13, 9:15 am, Dave Lowe <[EMAIL PROTECTED]> wrote:
> Ever since the querset-refactor merge, params in the 'tables' argument
> don't seem to be filled. The documentation d
That's much more clear than what I had been reading.
If that is the case, then annotate would replace GROUP BY, and should
also be able to replace distinct().
On May 12, 9:27 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Tue, May 13, 2008 at 12:01 PM, David Cramer <[EMAIL PROTECTED]>
Ever since the querset-refactor merge, params in the 'tables' argument
don't seem to be filled. The documentation describes the arguments
'params' and 'select_params' as being for where and select statements,
respectively. Do we need a "tables_params" argument as well?
Here's a code sample of whe
Thanks for the sugestion Alex,
I will do that.
Also, Im glad to see you are following the updates closely :)
On Mon, May 12, 2008 at 10:26 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> Hey, just saw the update, and my suggestions would be, instead of
> using round() figure out how many
20 matches
Mail list logo
