Comments on: Django Site Module

By: Duc Nguyen

Duc Nguyen — Thu, 26 Jul 2007 01:57:24 +0000

Do you use any special IDE to write your python code? It seems outside of pydev or wingide, there aren’t really any good python IDE’s. Pydev and wingide aren’t that good anyways, so I’ve went back to using good old emacs to do the job.

By: Johnson Rice

Johnson Rice — Thu, 19 Jul 2007 03:14:06 +0000

Doubtfully a good time…

I’m just thinking the “Public” “Private” and “# Recipients” labels on each message should be subtly color coded so they stand out slightly more.

At least private messages should be… I’d like to know a little more clearly when a message is directed AT me specifically, or from me to someone specifically.

Although, that suggestion is probably ill timed and out of place here… Maybe.. I dunno. *shrug*

By: Matt

Matt — Thu, 19 Jul 2007 01:26:48 +0000

Django ate my baby!

(I had to say it)

By: Leah Culver

Leah Culver — Wed, 18 Jul 2007 21:27:00 +0000

Bob and Jacob - thanks for the tip about caching the context processors! I’ll do that.

By: Bob Ippolito

Bob Ippolito — Wed, 18 Jul 2007 17:21:07 +0000

I’m not sure what the request model looks like for Django, but we cache read-only queries like this in the request object so that it only gets fetched once per request. There’s also a tier of memcached between our webapps and the database, but making sure cached stuff doesn’t go stale is tricky.

By: Jacob Kaplan-Moss

Jacob Kaplan-Moss — Wed, 18 Jul 2007 16:52:15 +0000

@Leah: ah, that makes sense — context processors are executed each time a context (er, a RequestContext, that is) is initialized; depending on how things are written multiple contexts could be created on each request.

Sounds like your fix was easy enough; it should also be trivial to modify the context processor to cache its data (it’s a good practice to cache things like context processors if possible since it can be hard to predict how often they’ll get called).

@Mark: you’re probably just trolling, but I’ll pretend you asked a question: when you do an ORM lookup in Django it selects all columns by default (including whatever columns you used in the lookup). That’s because the time it takes for a database to return all columns is almost identical to the time it takes to return a subset of columns. In fact, in some edge cases fewer columns can actually be slower.

Oh, and Django enumerates the columns explicitly because SELECT * is evil.

By: Jared

Jared — Wed, 18 Jul 2007 13:01:03 +0000

You know, you wouldn’t having this problem if you’d used Ruby on Rails. Sorry, I had to. Blame Canada? P.S. Hello from a fellow Minnesotan.

By: Uros Trebec

Uros Trebec — Wed, 18 Jul 2007 11:09:54 +0000

Leah - I had the same problem and found a fairly simple solution…
I’ve added the two variables to the settings.py file

ie.:
SITE_NAME = ‘Something’
SITE_URL = ‘http://something.com’

and then import them into context_processors.py with:
from django.conf import settings.SITE_NAME, settings.SITE_URL

This works really well for one-site projects (the majority of my sites). While I do understand the usefulness of contrib.sites for larger multi-sites, I think there’s too much overhead for one-site projects.

BTW, great job with Pownce! I’ve just got my invite yesterday and have yet to get my friends to join, but I like it so far.

By: Arne

Arne — Wed, 18 Jul 2007 07:48:18 +0000

I tried to remove the sites module from my django project to but then the flatpages fallback middleware complained, because there is a dependency on the sites module …

By: robert

robert — Wed, 18 Jul 2007 05:25:30 +0000

you know those posts you wrote about computer science classes? i wish my school would have merged programming and sql courses, now i know how to do sql, and i know how to program but i don’t know how to make them work together well.