#django

why is it not valid to import a model any time, though? is it a circular import issue? that's what seems to come up in conversation when i google get_model() and app cache etc… but i dont see any circular imports here…my middleware module has 1 middleware class… the module imports another module that has 1 class and 1 function and imports User which is used by the class…

well, it's just a sequencing issue

it's something that was so bad, they fixed it in 1.7

because you had no guaranteed order of startup or imports

morning, elbaschid

morning

is gunicorn the current best for serving?

it's one of the preferred

is it basically between uwsgi and gunicorn?

or waitress?

v0lksman: they're the most popular, with probably mod_wsgi next

__machine: wossat?

FunkyBob: does django have to call get_apps() before i can safely import models? e.g. is it just that i am importing *any* model too soon (in middleware module) or is it that this particular import is triggering some other imoprts that are doing something weird?

FunkyBob: I'm using mod_wsgi in apache on my staging/prod but uwsgi on dev...dev responds in 50ms...prod/stage ~140ms

__machine: so waitress is a competitor to gunicorn?

v0lksman: unfair comparison

whysat?

v0lksman: how much of that 140ms is apache handling and forwarding the request?

with uwsgi, are you having it serve directly, or is it behind, say, nginx?

forwarding where? both have nginx sitting out front...

Hey, given I have Model A with likes=ManyToManyField(User, related_name='herps'), how can I return a queryset of A, aggregating the number of likes owned by a given user? If I want to use Django ORM, do I absolutely have to perform SELECT (subquery) in .extra({'select': ..}) ?

so apache and uwsgi are the final destination..doing most of the work (there is no static to serve as it's an API)

FunkyBob: i guess so… i recall reading a few articles about waitress being better for django than gunicorn, at least on heroku… apparently gunicorn is meant to be used behind a buffering reverse proxy but waitress supports request and response buffering to protect your app from slow network clients…

v0lksman: so... you have nginx proxying to apache? why?

v0lksman: no wonder it's slower, youh've TWO web servers in front of your app server there

__machine: so waitress is intended to be raw internet facing?

FunkyBob: just habit. the only static the app serves is for the admin

v0lksman: really realyl wish they'd cut that doco... it only confuses people

v0lksman: apache can serve your static just fine

if you're going to have nginx there anyway, then sure, switch to gunicorn or uwsgi...

yeah...I doubt the problem is with nginx.

Can auth permissions still be used with custom user models?

v0lksman: no, the problem is hving two web servers parse your request before it reaches django

pilgo: yes, of course

FunkyBob: i dont know… probably not in the general case for django… its probably just a slightly better fit for heroku's setup

pilgo: that's why there's the permissions mixin

__machine: well, worth a look

FunkyBob: Ah, ok. Wasn’t sure since the “full example” in the documentation returns true always in permission methods

they say if you have slow clients with gunicorn you can use async workers but that will open a bazillion network connections… so waitress is better with its buffered requests and responses

"Waitress differs, in that it has an async master process that buffers the entire client body before passing it onto a sync worker. Thus, the server is resilient to slow clients, but is also guaranteed to process a maximum of (default) 4 requests at once. This saves the database from overload, and makes scaling services much more predictable."

__machine: debatable

in the case where your app is not behind a buffering reverse proxy server, sounds reasonable :) gunicorn will run a few sync workers and if you get a lot of slow clients it wont be able to satisfy requests… async worker will just open a database connection for every simultaneous request and your connection pool will be full… waitress will buffer the requests so all your sync workers are always busy without going crazyâ

sure

HI :) Q: I try to use this snipped from mambo user: https://djangosnippets.org/snippets/1054/ but i get maximum recursion depth exceeded ... when i return form in: def get_form(self, request, obj=None):

hetii: dpaste your code

FunkyBob: http://pastebin.com/VsH05hzm

Exception Location: ... /site-packages/django/contrib/admin/options.py in get_fieldsets, line 489

FunkyBob: ok i fixed it

Ahoy.

tswett: hoy you too :>

hetii: what was it?

Out of curiosity, is there an argument to authenticate() that makes it always succeed, even without a valid password?

no

FunkyBob: instead fields=[] in get_form() i use **kwargs and pass it also for super()

makes sense