Hi all,
In implementing this I ran into a bug in the way SQLite returns column
information: https://code.djangoproject.com/ticket/21603
It affects raw queries in general, but this feature in particular due to
the way the code generate nested SQL queries.
Cheers,
Alex
On Friday, December
Hi Anssi,
Getting back to this, a year later...I've created a branch on my fork and
opened a ticket on Trac.
My feature branch:
https://github.com/AlexHill/django/compare/master...raw_subqueries
Ticket on Trac, with more responses based on your comments above:
On 6 syys, 11:22, Alex Hill wrote:
> Hi Anssi,
>
> Thanks for your feedback! Responses inline.
>
> 1. It should not be assumed that the primary key is the field needed
>
> > in the inner query. We do have foreign keys to other fields, and one
> > can use this approach without
Hi Anssi,
Thanks for your feedback! Responses inline.
1. It should not be assumed that the primary key is the field needed
> in the inner query. We do have foreign keys to other fields, and one
> can use this approach without foreign keys at all.
Hmm, yes. Thinking about it, this seems
On 30 elo, 11:46, Alex Hill wrote:
> Hi, and thanks for making Django.
>
> At the moment, when passing a RawQuerySet to an __in filter, the raw query
> is evaluated and the result passed as a parameter to the filter's SQL. It
> would be nice to have the option of using the raw
Hi, and thanks for making Django.
At the moment, when passing a RawQuerySet to an __in filter, the raw query
is evaluated and the result passed as a parameter to the filter's SQL. It
would be nice to have the option of using the raw SQL in a subquery
instead, for performance reasons.
I think