Re: Use case for #14914 (to_db_python)

Thanks. I've had a look at GeoDjango and it did help. I've hacked something that works well enough for my purposes, but it assumes that the default connection is the one holding the data. I agree with you that it would be useful if the data mangling/demangling stage would be more easily overrid

Re: Use case for #14914 (to_db_python)

On Wednesday, August 7, 2013 5:22:29 PM UTC+10, Anssi Kääriäinen wrote: > > On Monday, August 5, 2013 8:02:52 AM UTC+3, Jani Tiainen wrote: >> >> Hi, >> >> You seem to found kind of an issue which happens with GeoDjango part as >> well. Most of the geodjango operations require quite heavy to/fr

Re: django.utils.functional.cached_property

On Thu, Aug 8, 2013, Russell Keith-Magee wrote: >One suggestion -- a new special topic guide on performance tweaking I'd like to take that on, if unless anyone else feels they should be responsible for it, since it will involve a certain amount of

InterfaceError: connection already closed Django 1.5

Hello! Sorry for bad English. I met the following error: Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 255, in __call__ response = self.get_response(request) File "/usr/local/lib/python2.7/dist-packages/django/core/ha

Re: django.utils.functional.cached_property

On Thu, Aug 8, 2013 at 7:40 PM, Daniele Procida wrote: > On Thu, Aug 8, 2013, Russell Keith-Magee wrote: > > >One suggestion -- a new special topic guide on performance tweaking > > > > I'd like to take that on, if unless anyone else feels they shoul

Re: InterfaceError: connection already closed Django 1.5

2013/8/8 > > That is the unit of a code was in section try...finally(in finnaly signal > was excited signals.request_finished), now it isn't present. > There is a feeling that in case of a code redoing it simply forgot to > consider. > If everything is made intentionally I ask to report about it (

Re: InterfaceError: connection already closed Django 1.5

The exception is excited after connection with a database was lost and again regenerated(I start the application, execute a command postgresql restart, refresh the page of application and receive this exception) -- You received this message because you are subscribed to the Google Groups "Djan

Re: InterfaceError: connection already closed Django 1.5

2013/8/8 > The exception is excited after connection with a database was lost and > again regenerated(I start the application, execute a command postgresql > restart, refresh the page of application and receive this exception) Have you turned on persistent connections? If so, you're seeing the

Re: django.utils.functional.cached_property

Hi, I have some minor nitpicks: 1. Unlike the standard @property, the current implementation of @cached_property doesn't allow for a docstring. 2. Calling `del obj.` before accessing the value or more then once in a row throws an AttributeError. Should I make a new ticket for that or just send a

Re: Security Advisory: BREACH and Django

> > I am doing something a little different with my CSRF tokens, and I believe it guards against BREACH. Instead of sending the token in the HTTP response, I am using javascript to read (and generate if needed) the CSRF token cookie. The javascript reads the token from the cookie and adds it a

Proposal: ./manage check to look for models.BooleanField() without default= value.

The new ./manage check command is for helping people upgrade to a new version of django. https://docs.djangoproject.com/en/dev/ref/django-admin/#check django1.6 changes models.BooleanField() to not default to False any more. This has already bitten me a few times. https://docs.djangoproject.com/

Re: Security Advisory: BREACH and Django

On 2013-08-08 09:59, Collin Anderson wrote: >> I am doing something a little different with my CSRF tokens, and >> I believe it guards against BREACH. > > Instead of sending the token in the HTTP response, I am using > javascript to read (and generate if needed) the CSRF token cookie. > The javasc

Re: Deprecate admindocs?

Looking at the code, we're only using docutils for parsing reST markup in docstrings. What if we made reST parsing (and docutils) optional? Seems to me admindocs would still be plenty helpful without it. > -- You received this message because you are subscribed to the Google Groups "Django de

Re: Proposal: ./manage check to look for models.BooleanField() without default= value.

Maybe do this only for 1.6/1.7 to give a grace period to the change? On Thu, Aug 8, 2013 at 1:25 PM, Collin Anderson wrote: > The new ./manage check command is for helping people upgrade to a new > version of django. > https://docs.djangoproject.com/en/dev/ref/django-admin/#check > > django1.6 ch

Re: Proposal: ./manage check to look for models.BooleanField() without default= value.

On Fri, Aug 9, 2013 at 1:25 AM, Collin Anderson wrote: > The new ./manage check command is for helping people upgrade to a new > version of django. > https://docs.djangoproject.com/en/dev/ref/django-admin/#check > > django1.6 changes models.BooleanField() to not default to False any more. > This h