Quoting PostreSQL docs:
> The DISTINCT ON clause is not part of the SQL standard and is sometimes considered bad style because of the potentially indeterminate nature of its results. With judicious use of GROUP BY and subqueries in FROM the construct can be avoided, but it is often the most convenient alternative.
It's also supported by Oracle, AFAIK.
--
Łukasz Rekucki
I forgot to mention there's a ticket to support it in ORM:
http://code.djangoproject.com/ticket/14139.
--
Łukasz Rekucki
I can't see an obvious fix here either.
Given the timeframe, we may need to roll back this fix, live with the
older bug, and look at it again in the 1.4 timeframe.
Yours,
Russ Magee %-)
It is not, although it can be emulated using an analytic query. I
tried adding this to the patch in #6422 some time ago, but I found
that the structure of an analytic query was going to be rather
complicated to shoe-horn that into the query compilation code. That
was before the SQL compiler was factored out of the query code, and I
haven't gotten around to trying again since.
Cheers,
Ian
I'm currently not familiar with the current code base--still catching up--but wouldn't it make sense to select
distinct on the primary key?
Kind regards
Michael
Should have done more searching, thanks for correcting me.
>I tried adding this to the patch in #6422 some time ago, but I found
> that the structure of an analytic query was going to be rather
> complicated to shoe-horn that into the query compilation code. That
> was before the SQL compiler was factored out of the query code, and I
> haven't gotten around to trying again since.
It's probably messy in general case, but maybe we can try emulating
this in this particular case. Using an ordinary DISTINCT in a subquery
seems to solve the issue:
base_query =
self.rel.to._default_manager.using(db).complex_filter(self.rel.limit_choices_to).values('id').distinct()
queryset = self.rel.to._default_manager.using(db).filter(pk=base_query)
--
Łukasz Rekucki
Yes, that looks like it should work. I expect it's probably less
efficient, but we may just have to live with that.