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