Malcolm,thanks very much.
i am a newbie for django, and i just finished one big site by reading
documents and getting help here. what i think now is to optimize it,
so i use cache,select_related and values.
you give me a whole picture of django queryset, i know the difference
now, thanks again!
On Feb 19, 12:19 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-02-17 at 22:22 -0800, [EMAIL PROTECTED] wrote:
> > i have 2 Models(for example):
> > one is Category, have 2 fields: title and slug, the other is Entry
> > with 4 fields: title, time,category(foreign key),content.
>
> > now i just want show entry title and category slug, so i use this
> > queryset:
> > e = Entry.objects.all().values('title','category')
> > the benefit is huge content will be omitted which can save database
> > traffic(i considered).
>
> > but now category.slug is none, how can i get related value of category
> > in this query?
> > (i changed to e =
> > Entry.objects.all().values('title','category').select_related(), the
> > result was same.)
>
> Asking for the values('category') on some level doesn't make sense,
> since category is a whole object, not a single value. In fact, Django
> will be returning you the value of the foreign key (an integer here).
>
> Firstly, this smells of premature optimisation. If you're not sure you
> need something, particularly if it doesn't work, don't use it until you
> are sure. Once a database has to select one column from a row in a
> table it is close to zero extra effort to select the remaining columns:
> it has most likely already read them from disk, since it has to read in
> units of a whole disk block, which is a number of kilobytes. A general
> rule of thumb in database query optimisation is that pulling out the
> data (as opposed to filtering, sorting and grouping) is a negligible
> amount of time. If it isn't, your query is so simple it doesn't matter
> anyway. Of course, like all rules of thumb, it's a generalisation based
> on experience and there are plenty of exceptions. But it does mean
> "don't worry about what probably doesn't matter until it does matter".
>
> Values() queries are faster in Django in some cases, but it's not
> because of the database activity. It's because creating Python objects
> doesn't take zero time and Django adds some overhead as well. If you're
> working with 50,000 - 100,000 rows of data, the difference can be quite
> noticeable. If you're working with a few dozen rows, not so much. Still,
> that is the reason values() exists, so that if you do not just need some
> specific pieces of information, you can pull them back and we only need
> to create a dictionary, not a whole object instance and emit the
> signals, etc.
>
> Secondly, select-_elated() is only an optimisation. It will never change
> the result set you ultimately have access to (even if you don't use
> select_related(), you'll have access to the fields on category from a
> normal Entry model. It will just require an extra database query). If
> there is a difference between what you can do with and without a
> select_related() call, it's a bug (and, yes, there are cases on trunk
> like this; they're all bugs).
>
> Thirdly, ticket #5768 is open to one day add support for values()
> queries across relations. See the comments there for what is involved in
> implementing this.
>
> Regards,
> Malcolm
>
> --
> I just got lost in thought. It was unfamiliar
> territory.http://www.pointy-stick.com/blog/- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
