Thanks for the input! So, I'm assuming by "easiest case" you mean just
calling LEFT OUTER JOINs. That's Rails behavior and then it deals with it
in Ruby. I'm not too familiar with SQLAlchemy, but it looks like that's
what they're doing in their EagerLoader as well.
The only way I can think of overcoming this would be to do an SQL UNION with
the LEFT OUTER JOIN in the union. That way you're doing one join per UNION
clause and should end up with X + Y rows (which is better in cases of many
multiple related objects, but in the case that there is 1 or none, would
actually add more to the return set). It's ugly because you have to specify
null fillers for the things that won't exist. As I realise how silly it was
to do an OUTER JOIN there, I retract and change it to INNER JOINs within the
UNIONs (since we don't need to get duplicate rows for relations that don't
exist).
That would seem to allow for decent iteration over something to propagate
the appropriate *_set list attributes.
To illustrate using the blog example (extended with an authors m2m
relationship so that an article can have many authors):
SELECT * FROM articles /*fill nulls for other columns, cut for readability*/
UNION
SELECT * FROM articles /*could also possibly just fill nulls for articles to
make the iteration easier*/
INNER JOIN comments ON comments.article_id=articles.id
UNION
SELECT * FROM articles
INNER JOIN authors_m2m_table ON authors_m2m_table.article_id=articles.id
INNER JOIN authors ON authors_m2m_table.author_id=authors.id
The problem with that is that any filters would have to be repeated multiple
times - like if you just wanted articles written by Malcom, you'd have to
add the explicit joins on each clause to the union.
Well, my brain has checked out for lunch so I think I'll follow it. Maybe
someone here has a better idea.
Sean.
On Mon, Feb 23, 2009 at 6:11 PM, Malcolm Tredinnick <
malc...@pointy-stick.com> wrote:
>
> On Mon, 2009-02-23 at 21:49 +0100, Torsten Bronger wrote:
> > Hallöchen!
> >
> > Alex Gaynor writes:
> >
> > > On Mon, Feb 23, 2009 at 12:40 PM, sphogan <spho...@gmail.com> wrote:
>
> [...]
> > >> What I would like to be able to do is:
> > >>
> > >> Article.objects.select_related('comment_set').all()
> > >>
> > >> This seems like a somewhat simple case and there seems to be no
> > >> mention of it in the documentation anywhere.
> > >
>
> > > That's not possible,
> >
>
> > By principle, or just because Django can't do it (yet)? The related
> > feature request can be found at
> > <http://code.djangoproject.com/ticket/2238>.
>
> Actually, this is really just a disguised version of #5768, which is
> talking about values() -- since that contains this problem plus the
> presentation issue subtlety. Read the comments there for information
> (I've repeated the basic hard part of this, below).
>
> > It it, I refer to
> >
> http://rubynugs.blogspot.com/2008/07/couple-of-stupid-things-about-djano.html
> > where a Rails fan claims that Rails can do it.
> >
> > I don't know much about SQL so I really would like to know whether
> > this could be realised.
>
> It's possible, but it's not at all trivial. Firstly, there's a
> representation issue for values(): there are multiple *_set rows
> returned for any individual result in the original query. So it requires
> a bunch more munging of results.
>
> Secondly, there's the "don't shoot yourself in the foot" issue, in that
> it's *very* easy to create a horribly inefficient query. The problem is
> when you start querying for both foo_set and bar_set. If they return X
> and Y results, respectively, for a given row, we need to make sure we
> only get back O(X + Y) results from the database, not O(X * Y) results.
> the simplest ways to construct the query for these multi-valued returns
> leads to the second case, so extra care has to be put into the situation
> with multiple multi-valued return results.
>
> We've always said we'll put this in once there's an excellent patch that
> avoids the second problem and has a decent return format for values()
>
> Hopefully that should put to rest all the debate in this thread about
> what's going on. We'll do, but somebody has to write the patch and it's
> not trivial. (That somebody might be me one day, but I also about a few
> hundred other things to work on in Django, so it's prioritised
> accordingly).
>
> Regards,
> Malcolm
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
