RE: template speed

2007-09-22 Thread Michael Elsdoerfer

> {% 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()

2007-09-13 Thread Michael Elsdoerfer

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: modeling db inheritance

2007-08-24 Thread Michael Elsdoerfer

I needed a very similar thing and I ultimately decided to use a "type" char
field in the base model that would contain the model name of the subtype.

Michael

> -Original Message-
> From: django-users@googlegroups.com [mailto:[EMAIL PROTECTED]
> On Behalf Of Ernesto Rodriguez Reina
> Sent: Friday, August 24, 2007 7:38 PM
> To: Django users
> Subject: modeling db inheritance
> 
> 
> Hello,
> I'm need to model a table inheritance in a new project i'm working on, but
> i
> don't know the best way to do it.
> 
> Here is an explample of what i need:
> 
> class User(models.Model):
>   firstname  = models.CharField(maxlength=100)
>   lastname  = models.CharField(maxlength=100)
> 
> # This should inherit User
> class Student(models.Model):
>   school= models.ForeignKey(School)
> 
> # This should inherit User
> class Teacher(models.Model):
>   school= models.ForeignKey(School)
>   students  = models.ManyToMany(Students)
> 
> # This should inherit User
> class Manager(models.Model):
>   pass
> 
> I think it could be adding a ForeingKey to User, but, how to know, having
> a
> User if it is Student, Teacher or Manager?
> 
> Any ideas?
> 
> Best Reagards,
> 
> --
> Lic. Ernesto Rodríguez Reina
> Facultad de Matemática y Computación, UH.
> http://profesores.matcom.uh.cu/~erreina/
> 
> 

--~--~-~--~~~---~--~~
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?

2007-08-19 Thread Michael Elsdoerfer

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?

2007-08-19 Thread Michael Elsdoerfer

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

2007-08-11 Thread Michael Elsdoerfer

> 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?

2007-08-04 Thread Michael Elsdoerfer

> 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

2007-07-31 Thread Michael Elsdoerfer

> 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?

2007-07-27 Thread Michael Elsdoerfer

> 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
-~--~~~~--~~--~--~---