Re: does django-admin need a man page?

Tim Graham writes: > I'd like to remove it though (or make it point people to 'django-admin > --help') as it's out-of-date and 'django-admin --help' provides the > same information in a much easier to maintain format. Does anyone else > have input on this? Man pages are a standard interface on U

does django-admin need a man page?

I raised the issue in #23903 and Aymeric mentioned that it may be useful for downstream packagers, e.g. Debian. I installed python-django via apt-get on Ubuntu 14.04 and confirmed the existence of the man page. I'd like to remove it though (or make i

Re: Configurable safety options for high performance Django systems

Thanks for the help but writing the custom database backend won't be a problem, I've written one before :) My goal was simply to move the Django project forward but it seems the problems I've encountered in the field are too uncommon for most other developers to care or understand. Thank you all

Re: Configurable safety options for high performance Django systems

On Mon, Nov 24, 2014 at 3:32 PM, Christophe Pettus wrote: > In your particular case, where you have the relatively unusual situation > that: > > 1. You have this problem, and, > 2. You can't fix the code to solve this problem. > > ... you probably have the right answer is having a local patch for

Re: Configurable safety options for high performance Django systems

On Nov 24, 2014, at 11:16 AM, Rick van Hattem wrote: > It seems you are misunderstanding what I am trying to do here. The 10,000 (or > whatever, that should be configurable) is a number large enough not to bother > anyone but small enough not to trigger the OOM system. There are really only f

Re: Configurable safety options for high performance Django systems

It seems you are misunderstanding what I am trying to do here. The 10,000 (or whatever, that should be configurable) is a number large enough not to bother anyone but small enough not to trigger the OOM system. In that case it works perfectly. Due note that the proposed solution is not a hypotheti

Re: Configurable safety options for high performance Django systems

On Nov 24, 2014, at 3:36 AM, Rick van Hattem wrote: > If you fetch N+1 items you know if there are over N items in your list. Let's stop there. Unfortunately, because of the way libpq works, just sending the query and checking the result set size won't solve your problem, except for an even s

[Re]launching DEPs

Hi folks - tldr: there's a new DEP 1 (https://github.com/django/deps/blob/master/final/0001-dep-process.rst), read it if you think you might want to submit a DEP. The biggest change is a clear articulation of exactly how the process works. Read on for background and more details. About six mo

Re: Configurable safety options for high performance Django systems

Hi Christophe, As I previously explained, there's no need for a roundtrip or different transactions levels. If you fetch N+1 items you know if there are over N items in your list. So with that in mind you can simply do a query with a limit of N+1 to know if your query returns over N items. No ne

Re: Configurable safety options for high performance Django systems

On Nov 24, 2014, at 1:08 AM, Rick van Hattem wrote: > Indeed, except it's not an "except: pass" but an "except: raise" which I'm > proposing. Which makes a world of difference. Well, as previously noted, this option would introduce another round-trip into every database if it's actually going

Re: Configurable safety options for high performance Django systems

On 23 November 2014 at 22:57, Christophe Pettus wrote: > > On Nov 23, 2014, at 1:53 PM, Rick van Hattem wrote: > > > Very true, that's a fair point. That's why I'm opting for a configurable > option. Patching this within Django has saved me in quite a few cases but > it can have drawbacks. > > A

Re: Configurable safety options for high performance Django systems

If that is an option than it's definitely a better location to set limits to prevent the server from going down. It helps nothing when it comes to debugging though. Which is the primary reason for patching the orm. And in addition to that, quite a few customers won't let you change the hosting se

Re: Configurable safety options for high performance Django systems

Since your use case seems to be "avoid blocking the server when one pageview uses unexpectedly many resources", and you don't want to fix or optimise the actual application code, why not set these limits at a level where it makes sense? For example: * http://uwsgi-docs.readthedocs.org/en/latest