On Sun, Nov 2, 2008 at 6:54 AM, Tai Lee <[EMAIL PROTECTED]> wrote:
> I've put this ticket back to "accepted" as per your comment that the
> bug should be fixed. As you say, the DDN and confused comments were
> not intended to raise a red flag, and should have been taken to a
> separate ticket. The
On Nov 2, 10:57 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
>
> You do know that Karen has a commit bit, right? If she's got concerns
> about a ticket, then I at least take that as meaning it's got problems
> and isn't ready for checkin.
Yes, I did notice that. However, as I said, there is sti
On Nov 1, 2:52 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> To be clear, the generated cache key would still include anything
> stated in the HTTP Vary heads, right?
>
> Vary: Cookie combined with @vary_on_get() should still vary on Cookie.
>
Yes.
>
> I say cache nothing; doing otherwise is
I really like the idea of the explicit GET params passed.So I'm +1
especially on solution #3. I actually had never realized it wasn't
caching pages with GET params, luckily though, any pages where I use
this decorator don't fluctuate like that :)
On Nov 1, 7:51 pm, "Jeremy Dunck" <[EMAIL PROTECTE
Yes, that may be true.
But why does the 'default' behavior impose these dependencies when
they are not required? As that context processor has this other 'side
effect' of making an entire site "Vary" under a cookie, hit the
session and hit the DB.
and one would need to override every other funct
Would it be wise to suggest that it be removed from the django core
given the connection drops every request? It's not done for Postgres
at all and the Oracle base.py is doing what you suggest.
I guess this question would be posed to whomever controls that slice
of the django pie.
bo
On Nov 2
On Sun, Nov 2, 2008 at 5:54 AM, Tai Lee <[EMAIL PROTECTED]> wrote:
> There's still no comment in the ticket from a core developer or
> anybody else, though. As this is a simple bug fix, can I (as the
> reporter) mark this ready for checkin, as there is a patch with tests?
You do know that Karen h
Thanks for your feedback, Karen.
> http://code.djangoproject.com/ticket/8898
>
> I suspect this one may be stalled because it is in design decision needed
> state with a last comment that makes it sound like the existing patch (added
> before the last comment) is not correct and that the right fi
Oh, I forgot to mention that this is certainly a Django issue and not
a mysqldb issue. The relevant code is in django/db/backends/mysql/
base.py:232:
def _valid_connection(self):
if self.connection is not None:
try:
self.connection.ping()
re
Yeah, we found the ping() during performance profiling too. It's a
significant performance hit -- it basically doubles the number of
requests to the DB server. It seems that the reason is to support use
cases where the DB connection is long-lived, since sometimes DB
connections die if you leave th
10 matches
Mail list logo
