RE: template speed
> {% ifequal newsitem.user.id 12 %}
Just a guess, but is it possible that this requires a separate query for the
user for each item in object_list?
Michael
> -Original Message-
> From: django-users@googlegroups.com [mailto:[EMAIL PROTECTED]
> On Behalf Of [EMAIL PROTECTED]
> Sent: Saturday, September 22, 2007 2:25 PM
> To: Django users
> Subject: template speed
>
>
> Hello.
>
> I'm worrying about my django-app setted up on mod_python 3.3.1+apache
> 2.0.59 speed.
> I have this model http://dpaste.com/20362/. On production server
> (Pentium D, 2Gb RAM) with all DEBUG turned off and StatsMiddleware
> from (http://code.djangoproject.com/wiki/PageStatsMiddleware to get
> page generation time) i've tested two different templates (both
> rendered by object_list generic view):
>
> First:
> {%for object in object_list%}
> {{object}}
> {%endfor%}
>
> Gives about 0.013 - 0.023sec page generation time
>
> Second more complicated (most of HTML code removed to improve
> reading):
>
> {% for newsitem in object_list %}
>
> {{ newsitem.title }}
> {{ newsitem.pdate|date:"j.m.Y" }}
>
> {% ifequal newsitem.user.id 12 %}
> {{ newsitem.author }} |
> {% else %}
> {{ newsitem.user.username }} |
> {% endifequal %}
>
>
> {{ newsitem.brief|striptags }}
>
>
> {% endfor %}
>
> This gives ten times more: 0.1-0.14 secs, in both cases SQL time was
> like 0.006-0.008 secs.
> Is it normal, that this very simple code take ten times more
> processing? You see that i don't make any manytomany relationship
> lookups neither some heavy func calls.
>
> Plus to this, ab testing (ab -n100 -c 15) gives about 5 req/sec which
> is pretty slow, i think.
>
>
> Regards, Dmitry.
>
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
reverse select_related()
I am using a unique=True foreign key relationship to model inheritance, as suggested by the documentation. Say a TypedItem model that has a FK to BaseItem. Now I am in a situation where it would be really nice to be able to access the typed item from within the base item, e.g. the one row in BaseItem.typeditem_set. Unfortunately, for a large number of BaseItems, that quickly starts to be come suboptimal, as the db is queried at least once for each, and select_related() only works the other way round, e.g. will not cache the reverse set. Any ideas on how to approach this? Thanks, Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
RE: TIME_ZONE setting: How does it work?
Malcom, Thank you for the elaborate explanation. That fixed the problem, and I actually understood it ;) Michael > -Original Message- > From: django-users@googlegroups.com [mailto:[EMAIL PROTECTED] > On Behalf Of Malcolm Tredinnick > Sent: Sunday, August 19, 2007 11:54 AM > To: django-users@googlegroups.com > Subject: Re: TIME_ZONE setting: How does it work? > > > On Sun, 2007-08-19 at 11:15 +0200, Michael Elsdoerfer wrote: > > I'm having some trouble with time zones on my production machine > (debian, > > apache prefork with mod_python). On Windows, everything works as > expected. > > I'm running the trunk from maybe two weeks ago. > > More accurately, on Windows, Django's timezone stuff does absolutely > nothing. Setting timezones on Windows requires code we don't have > (there's an open invitation for somebody to write the necessary code if > they need it), so we don't modify the environment at all. > > > Basically, I have TIME_ZONE = 'GMT+1', but while > datetime.datetime.today() > > in a vanilla python shell returns the correct date, the same in > manage.py > > shell does not (off by 3 hours). > > You've fallen into a common trap with POSIX timezone specifications, > which is what are being used here. > > The string "GMT+1" actually means (in POSIX terms) "my timezone is > called 'GMT' and it is one hour *west* of the Prime Meridian." The > format is parsed as "name + offset" where offset is negative for East > and positive for West -- it's the number of hours you add to localtime > to get UTC, instead of vice-versa. > > Based on your e-mail headers, it looks like you are in the Central > European timezone and, since it's summer time, one hour behind UTC (west > of the Prime Meridian) is three hours behind your current timezone, > which is what you are seeing. > > So, either use something like "CET-2" or use the more descriptive names. > These names used to be in the PostgreSQL documentation, but I just > noticed that they have been removed in the latest version. So check a > slightly older version of the PostgreSQL documentation (using a similar > link to that in settings.py above TIME_ZONE) for some examples. > > > While I try to figure this out, allow me a more general question. It > seems > > every time I change the time zone, the date that gets written to my > MySQL > > database changes. > > > > Frankly, what I would have expected is: The values stored in the backend > > remain the same, only when read are interpreted differently. Isn't that > how > > it *should* work? Although I am always confused by time zones, so maybe > I'm > > way off here. > > Django doesn't support datetime fields with timezones. Instead, it > writes the time to the database using the local time (as configured via > the TIME_ZONE setting). This isn't particularly optimal in a number of > cases, but reflects Django's historical usage where the server was only > serving one timezone and never changing, etc. I would expect that to be > fixed in some fashion in the future, because it's hardly uncommon to > have to store multiple time-zoned information (even the Lawrence guys > are discovering this, I gather). There are also problems with corrupting > the environment for other processes by setting the TZ environment > variable. > > Tom Tobin has opened a ticket in Trac, volunteering to take on this > effort. I am fully behind it in the broader sense (although he doesn't > seem to have proposed using timezone-aware database fields yet, which is > the best solution a lot of times). > > > What am I missing? > > Don't let your assumptions lead you around by the nose. :-) > > Cheers, > Malcolm > > -- > Honk if you love peace and quiet. > http://www.pointy-stick.com/blog/ > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
TIME_ZONE setting: How does it work?
I'm having some trouble with time zones on my production machine (debian, apache prefork with mod_python). On Windows, everything works as expected. I'm running the trunk from maybe two weeks ago. Basically, I have TIME_ZONE = 'GMT+1', but while datetime.datetime.today() in a vanilla python shell returns the correct date, the same in manage.py shell does not (off by 3 hours). While I try to figure this out, allow me a more general question. It seems every time I change the time zone, the date that gets written to my MySQL database changes. Frankly, what I would have expected is: The values stored in the backend remain the same, only when read are interpreted differently. Isn't that how it *should* work? Although I am always confused by time zones, so maybe I'm way off here. What am I missing? Thanks, Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
RE: Support for macros in templates
> If interested, take the library from here:
> http://www.djangosnippets.org/snippets/363/
Interesting. I too was missing macro support, and implemented something
similar a couple weeks ago:
http://www.djangosnippets.org/snippets/343/
Michael
> -Original Message-
> From: django-users@googlegroups.com [mailto:[EMAIL PROTECTED]
> On Behalf Of Michal Ludvig
> Sent: Saturday, August 11, 2007 4:51 AM
> To: django-users@googlegroups.com
> Subject: Support for macros in templates
>
>
> Hi all,
>
> This is a little announcement of a tag library for {% macro %} support
> in Django templates.
>
> I have been using TAL template engine in my previous project and got
> used to the concept of "macros" as building blocks of the final HTML
> output. Now in Django I realised the missing support for "macros" is a
> serious limitation. I admit I may be too locked to a different mindset
> and perhaps the same things I need macros for could be achieved with
> pure Django templates. Maybe, maybe not. Anyway, I was missing macros so
> much that I decided to add them to Django.
>
> If interested, take the library from here:
> http://www.djangosnippets.org/snippets/363/
>
> Usage is like this:
>
> 1) Load the macro library:
> {% load macros %}
>
> 2) Define a new macro called 'my_macro'
>with parameter 'arg1':
> {% macro my_macro arg1 %}
> Parameter: {{ arg1 }}
> {% endmacro %}
>
> 3) Use the macro with a String parameter:
> {% usemacro my_macro "String parameter" %}
>
>or with a variable parameter (provided the
>Context defines 'somearg' variable, e.g. with
>value "Variable parameter"):
> {% usemacro my_macro somearg %}
>
> The output of the above code would be:
> Parameter: String parameter
> Parameter: Variable parameter
>
> It works pretty well and the only drawback is that the defined macros
> are local to each template file, i.e. are not inherited through
> {%extends ...%} and you can't have for instance some common macros
> defined in a separate file and include that file wherever needed. I'll
> try to solve that problem later. Perhaps through a new tag, for instance
> {%macrofile ...%} or something like that. Maybe someone will contribute
> a patch? ;-)
>
> Enjoy and sorry for the spam
>
> Michal
> --
> * http://www.logix.cz/michal
>
>
>
>
>
>
>
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
RE: Only save if changed?
> def save(self): > if self.id is not None: > old_self = self.__class__.get(id = self.id) > if self.id is None or (old_self.city != self.city) or ( > old_self.state != self.state): > self.geocode = self.get_geocode() > super(SiteUser, self).save() You can also monitor attribute changes via __setattr__, which will save you an additional query. That worked fine for me so far, although I am not 100% if there might not be some edge cases that could cause problems. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
RE: how to overcome {% if %} limitation
> 2) create custom tag.
Some people have already done this of course, for example:
http://www.djangosnippets.org/snippets/130/
Michael
> -Original Message-
> From: django-users@googlegroups.com [mailto:[EMAIL PROTECTED]
> On Behalf Of [EMAIL PROTECTED]
> Sent: Tuesday, July 31, 2007 9:49 AM
> To: Django users
> Subject: Re: how to overcome {% if %} limitation
>
>
> 1) (better!) do this in a view. pass a flag 'more_then_10' to
> template.
> 2) create custom tag.
>
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
RE: Is cloning Facebook in Django feasible?
> And yes, facebook has been cloned in other countries, many, many times. > The most famous one is from china: http://xiaonei.com/ Not only did > they clone the features, they cloned the interface. It even got > acquired for lots of money. Or in Germany StudiVZ, which also got acquired. As some server path-leaks in PHP errors revealed, they apparently called their app "Fakebook" internally, which I thought was kind of clever ;) Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
