The second parameter "fields" has not been added yet. It can help
reduce DB load a lot, especially when you are having deeply related
models, which seems a normal thing to me. For example:
class NewsTicker(models.Model):
id = models.AutoField(primary_key=True)
user = models.ForeignKey(User)
class UserProfile(models.Model):
user = models.ForeignKey(User, unique=True)
last_news = models.ForeignKey(NewsTicker, default=0)
UserProfile.objects.select_related().get(user__id=3)
this query ^^^ joins four tables (user table twice). But I am
currently not interested in the newsticker stuff, which causes to add
two tables (newsticker and user for the 2nd time).
see here: SELECT ... FROM `core_userprofile` , `auth_user`,
`core_newsticker`, `auth_user` `auth_user3`
With the fields parameter I could reduce the DB load a bit, which is relevant.
Calling:
UserProfile.objects.select_related(fields=["user"]).get(user__id=3)
which would result in
SELECT ... FROM `core_userprofile` , `auth_user`
would help a lot.
1) How can I help getting this functionality into trunk? (enhance the
patch, write doc, ...)
2) Is this something that would be accepted to go into the trunk at all?
thanks
--
cu
Wolfram
When I worked on this, the "fields" bits from the patch didn't seem to
work for me (at least, not in the way I expected -- which is as you
described it).
If you want to take another crack at it, please feel free! I'm
probably closer to -0 on the functionality, but a working patch might
push me closer to +0. I can't speak for the other devs, but I suspect
they'll say similar things.
Jacob
I will give it a shot, thanks for the quick reply.
Just for curiosity, why does this not seem interesting to you? Do you
never use it? Are your models never interconnected over multiple
levels? Did the overhead never bother you? Whats the reason?
Wolfram
> Jacob
>
> >
>
--
cu
Wolfram