On Tue, Feb 23, 2010 at 10:42 AM, felix wrote:
>
> On Feb 23, 12:32 am, Russell Keith-Magee
> wrote:
>
>> To reinforce my point - if you're using Django's ORM, you shouldn't
>> have to care about the underlying query. The ORM *should* be
>>
On Feb 23, 12:32 am, Russell Keith-Magee
wrote:
> To reinforce my point - if you're using Django's ORM, you shouldn't
> have to care about the underlying query. The ORM *should* be
> abstracting these details so that you don't care. I realize that
> inspecting query
On Tue, Feb 23, 2010 at 1:17 AM, felix wrote:
>
> On Feb 22, 9:22 am, Russell Keith-Magee
> wrote:
>> > However getting the SQL that will be produced is essential. There
>> > needs to be a utility method somewhere that will give us this sql and
>>
On Feb 22, 9:22 am, Russell Keith-Magee
wrote:
> > However getting the SQL that will be produced is essential. There
> > needs to be a utility method somewhere that will give us this sql and
> > it needs to remain stable.
>
> Well, no -- it isn't essential. It might be
On Mon, Feb 22, 2010 at 2:41 AM, felix wrote:
> As of 1.2 and multi-db how do I get the sql that will be produced from
> a query set ?
>
> Since 1.2 and multi-db, the previous methods are no longer working.
> Its been said here that we shouldn't depend on internal
from django.db import connections
def dbug():
pdb.set_trace()
def qbug(qs,caption=""):
connection = connections['default']
aa,bb=qs._as_sql(connection)
print caption, aa % bb
return qs
--
You received this message because you are subscribed to the Google Groups
"Django
As of 1.2 and multi-db how do I get the sql that will be produced from
a query set ?
Since 1.2 and multi-db, the previous methods are no longer working.
Its been said here that we shouldn't depend on internal functions as
they may change.
However getting the SQL that will be produced is
7 matches
Mail list logo