On 4/6/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Lachlan Cannon wrote:
> >
> > We have urls.py already, which maps urls -> views. Most of the proposals so
> > far
> > for getting urls back seem to have revolved around getting a url for a
> > model --
> > I think this is looking at the s
Adrian Holovaty wrote:
>Django has closed the database connection on every request for as long
>as I remember. The very first open-source version had it --
>http://code.djangoproject.com/browser/django/tags/notable_moments/ipo/django/core/handler.py#L32
>-- and we had that db.db.close() for every
On Apr 5, 2006, at 8:29 PM, Adrian Holovaty wrote:
> Django has closed the database connection on every request for as long
> as I remember. The very first open-source version had it --
> http://code.djangoproject.com/browser/django/tags/notable_moments/
> ipo/django/core/handler.py#L32
> -- and
Lachlan Cannon wrote:
>
> We have urls.py already, which maps urls -> views. Most of the proposals so
> far
> for getting urls back seem to have revolved around getting a url for a model
> --
> I think this is looking at the situation the wrong way. We're not redirecting
> people to an objec
> I don't understand how the traceback module ends up being None
> Adding a check for None will make the warning message go away
fixing up code to make a mysterious error message go away is vey very
suboptimal (ok ... so I've done I it myself a few times as well ...)
--~--~-~--~~--
Guys, I think maybe we're thinking about resolving urls the wrong way.
We have urls.py already, which maps urls -> views. Most of the proposals so far
for getting urls back seem to have revolved around getting a url for a model --
I think this is looking at the situation the wrong way. We're no
On 4/5/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Again, I really want to back this change out. My off-the-cuff
> measurements (not very good, probably) show about a 5% performance
> hit when closing the connection each time, and although that's not
> much, that's 5% less hardware I have
On 4/6/06, akaihola <[EMAIL PROTECTED]> wrote:
>
> My guess is that there's no way to do it on the db level. You can
> retrieve the results for both queries as lists and then merge:
> results = list(queryset1.filter(criteria...)) +
> list(queryset2.filter(criteria...))
> results.sort(lambda a, b:
On Wednesday 05 April 2006 23:07, gabor wrote:
> hi Jacob, many thanks for the explanation.
>
> (and sorry to jump into the discussion)..
>
> the original poster (luke plant) said that:
>
> "
> It appears
> that connections are not being closed at all. With every hit I'm
> getting another entry
Jacob Kaplan-Moss wrote:
>
> On Apr 5, 2006, at 2:09 PM, Ivan Sagalaev wrote:
>> How can this work? Django app connects to Postgres through psycopg,
>> how
>> Apache can "hold" the connections that it doesn't know anything about?
>> Or does it?
>
> It's not "holding" connections, per se... let
On Apr 5, 2006, at 4:01 PM, Rudolph wrote:
> I'm not an expert on this subject but if I understand it correctly the
> database should accept at least as many connections as Apache can
> handle client connections (and if that's too much, you can use
> pg_pool)? Allowing a bit more connections would
I'm not an expert on this subject but if I understand it correctly the
database should accept at least as many connections as Apache can
handle client connections (and if that's too much, you can use
pg_pool)? Allowing a bit more connections would be nice otherwise you
can't at the same time conne
On Apr 5, 2006, at 2:09 PM, Ivan Sagalaev wrote:
> How can this work? Django app connects to Postgres through psycopg,
> how
> Apache can "hold" the connections that it doesn't know anything about?
> Or does it?
It's not "holding" connections, per se... let me see if I can explain
it more cl
My guess is that there's no way to do it on the db level. You can
retrieve the results for both queries as lists and then merge:
results = list(queryset1.filter(criteria...)) +
list(queryset2.filter(criteria...))
results.sort(lambda a, b: cmp(a.date, b.date))
--~--~-~--~~
Jacob Kaplan-Moss wrote:
>It's not pooling per se; it's persistent connections. What happens
>is that when the request ends the Apache process isn't gc'd so the
>connection stays open. When the next request comes in to the same
>child, the connection is reused.
>
>
How can this work? Dj
On Apr 5, 2006, at 1:18 PM, Ivan Sagalaev wrote:
> The problem is that Django does not reuse these open connections. Each
> new request always asks psycopg to open a new one and the old one
> never
> used. AFAIK Apache alone can't magically provide connection pooling.
It's not pooling per se; i
Jacob Kaplan-Moss wrote:
>Now, it's not that closing these connections at the end of each
>request is bad per se, but it is the case that creating new
>connections to PostgreSQL is actually pretty expensive, and so
>reusing connections gives a small but measurable performance
>increase.
>
On Apr 4, 2006, at 4:43 PM, Luke Plant wrote:
> I'm nervous about committing this, because it might mess something up
> for someone else. Can anyone comment on the original version?
> (apologies in advance for the mangled diff).
I'm not so sure this is a good idea...
When PostgreSQL reports a i
Nebojsa Djordjevic <[EMAIL PROTECTED]> writes:
> Luke Plant wrote:
>> On Wednesday 05 April 2006 00:31, Adrian Holovaty wrote:
>>
>>> If that fixes the problem, go ahead and commit it -- it doesn't
>>> seem like the type of change that would cause problems. Thanks for
>>> catching this!
>> OK,
Luke Plant wrote:
> On Wednesday 05 April 2006 00:31, Adrian Holovaty wrote:
>
>> If that fixes the problem, go ahead and commit it -- it doesn't seem
>> like the type of change that would cause problems. Thanks for
>> catching this!
>
> OK, I've committed, and it seems to work fine. I've found
On Wednesday 05 April 2006 00:31, Adrian Holovaty wrote:
> If that fixes the problem, go ahead and commit it -- it doesn't seem
> like the type of change that would cause problems. Thanks for
> catching this!
OK, I've committed, and it seems to work fine. I've found one thing
that worries me t
Say I have a digest and blog model, and I also need to search from
them. And the results will come from two tables, and how to easily
merge them, and sort the result by date? Or there is an alternative
way to do such thing?
--
I like python!
My Blog: http://www.donews.net/limodou
My Django Site:
22 matches
Mail list logo
