Queryset-refactor branch has been merged into trunk

[Malcolm Tredinnick]

I merged queryset-refactor into trunk just now. This was changeset
r7477.

There are still a couple of enhancements to do, but I've decided they're
not worth holding up the entire branch for. I can just as easily do them
on trunk.

Thanks to everybody who reported bugs and tested things. Thanks
especially to Justin Bronn and Ian Kelly for lots of patches and testing
to get the Oracle backend up to scratch on the branch.

Detailed list of changes is in the branch's wiki page ([1]) and if
you're interested in seeing the documentation additions and changes, you
can view [2].

[1] http://code.djangoproject.com/wiki/QuerysetRefactorBranch
[2] http://code.djangoproject.com/changeset?new=django%2Ftrunk%2Fdocs%
407477&old=django%2Ftrunk%2Fdocs%407411

No more bugs should now be reported against the queryset-refactor
version. The branch is closed.

Regards,
Malcolm

--
On the other hand, you have different fingers.
http://www.pointy-stick.com/blog/

[Russell Keith-Magee]

On Sun, Apr 27, 2008 at 11:04 AM, Malcolm Tredinnick
<mal...@pointy-stick.com> wrote:
>
> I merged queryset-refactor into trunk just now. This was changeset
> r7477.

w00t! Great work Malcolm. This is a big change, a long time coming,
but well worth the wait. Thanks for all the effort you have put into
getting this done.

Russ %-)

[Mike Scott]

Congratulations Malcolm,

You very much deserve a big pat on the back for the entirety of the work you have done.

We've been testing on 3 of our websites the QS-RF branch, with little to no issues, and lots of benefits.

Regards,


Mike Scott

[alex....@gmail.com]

Massive congratulations and thanks all around, and to Malcolm!

On Apr 27, 1:04 am, "Mike Scott" <mic...@gmail.com> wrote:
> Congratulations Malcolm,
>
> You very much deserve a big pat on the back for the entirety of the work you
> have done.
>
> We've been testing on 3 of our websites the QS-RF branch, with little to no
> issues, and lots of benefits.
>
> Regards,
>
> Mike Scott
>

> On Sun, Apr 27, 2008 at 5:46 PM, Russell Keith-Magee <freakboy3...@gmail.com>

[Simon Willison]

On Apr 27, 4:04 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

> I merged queryset-refactor into trunk just now. This was changeset
> r7477.

Fantastic! Congratulations, and thank you.

One of my favourite new features is the ability to more easily see the
SQL that is going to be run against the database for a given queryset,
using the new .query and .query.as_sql() methods:

>>> print Woo.objects.filter(name='Hello').query
SELECT "demo_woo"."id", "demo_woo"."name", "demo_woo"."when",
"demo_woo"."description" FROM "demo_woo" WHERE "demo_woo"."name" =
Hello
>>> print Woo.objects.filter(name='Hello').query.as_sql()
('SELECT "demo_woo"."id", "demo_woo"."name", "demo_woo"."when",
"demo_woo"."description" FROM "demo_woo" WHERE "demo_woo"."name" = %s
', ('Hello',))

Is there any reason these aren't documented? I was going to add them
to the wiki page but I wasn't sure if they were intended as internal-
only features that may change in the future.

Also, how hard would it be to get the __str__() representation of a
Query to be escaped using the current database's escaping syntax? It
seems like it could be a bit of a fiddle as Python's DB-API doesn't
require database engines to expose that ability, but it would be
extremely useful for testing - it would mean you could copy and paste
SQL directly from Python's interactive prompt (or from the Django SQL
query log) and paste it in to a mysql interactive shell, which would
help with debugging tricky SQL.

Cheers,

Simon

[Bryan Veloso]

Indeed! Congrats! Now we need to get brosner to throw this into NFA so
us branchies can start playing with it as well. :)

On Apr 26, 11:30 pm, "alex.gay...@gmail.com" <alex.gay...@gmail.com>
wrote:

[Malcolm Tredinnick]

On Sun, 2008-04-27 at 00:19 -0700, Simon Willison wrote:
[...]

> One of my favourite new features is the ability to more easily see the
> SQL that is going to be run against the database for a given queryset,
> using the new .query and .query.as_sql() methods:
>
> >>> print Woo.objects.filter(name='Hello').query
> SELECT "demo_woo"."id", "demo_woo"."name", "demo_woo"."when",
> "demo_woo"."description" FROM "demo_woo" WHERE "demo_woo"."name" =
> Hello
> >>> print Woo.objects.filter(name='Hello').query.as_sql()
> ('SELECT "demo_woo"."id", "demo_woo"."name", "demo_woo"."when",
> "demo_woo"."description" FROM "demo_woo" WHERE "demo_woo"."name" = %s
> ', ('Hello',))
>
> Is there any reason these aren't documented? I was going to add them
> to the wiki page but I wasn't sure if they were intended as internal-
> only features that may change in the future.

I doubt that they're likely to change. as_sql() is basically the
"public" (in the sense that Query isn't public API, but it's
developer-exposed API) way to get the SQL -- particularly needed for
writing subqueries and the like.

At some point we need to update the FAQ question, since as_sql() is
equivalent to, but easier than, db.connection.queries[-1]['sql'] (and
happens before the event).

Note, however, that as_sql() doesn't always return something. There is a
shortcut built in when we know nothing can match (the
MyModel.objects.filter(pk__in=[]) situation) and in that case as_sql()
will raise an exception which is caught in the database execution code;
i.e. it's a feature, not a bug. That's rare enough not to be a real
problem, though, and if MySQL didn't misimplement "pk is NULL" by
overloading its behaviour we wouldn't even need that (although the
shortcut is faster).

> Also, how hard would it be to get the __str__() representation of a
> Query to be escaped using the current database's escaping syntax? It
> seems like it could be a bit of a fiddle as Python's DB-API doesn't
> require database engines to expose that ability,

Well, that's really the problem: it's not exposed at all, so would
require extra code for every single backend, since it requires diving
into undocumented interfaces in some cases. For this reason, I've
personally gotten into the habit of only using as_sql(), so that it's
clear where the parameters will be substituted and what the parameters
are. I find the __str__() output a little harder to parse.

> but it would be
> extremely useful for testing - it would mean you could copy and paste
> SQL directly from Python's interactive prompt (or from the Django SQL
> query log) and paste it in to a mysql interactive shell, which would
> help with debugging tricky SQL.

Agreed, in theory. We take patches. :-)

I seem to remember I've fallen into the trap of implementing some of
your personal "wouldn't it be nice if..." features before. I'm wiser
now.

Regards,
Malcolm

--
Everything is _not_ based on faith... take my word for it.
http://www.pointy-stick.com/blog/

[mtrier]

Malcolm,

Thank you so much for everything you do to help this project. Just
based on changeset dates and time I know that you have put in
countless hours to get this work done. It's much appreciated.

> Indeed! Congrats! Now we need to get brosner to throw this into NFA so
> us branchies can start playing with it as well. :)

Looks like that's done in http://code.djangoproject.com/changeset/7479.
Thanks Brian.

Michael Trier
blog.michaeltrier.com

[flo...@gmail.com]

Malcolm, thank you so much for all the work that you've done. It
benefits so many people! Hopefully you can see just how much your
hard work is really appreciated by all of the positive vibes in the
internet tubes right now :)

[Kenneth Gonsalves]

On 27-Apr-08, at 8:34 AM, Malcolm Tredinnick wrote:

> I merged queryset-refactor into trunk just now. This was changeset
> r7477.

w000t - thanks and congratulations Malcolm, you rock

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/code/

[Don Spaulding II]

Malcolm Tredinnick wrote:

I merged queryset-refactor into trunk just now. This was changeset
r7477.

Thanks for all of your effort on this, Malcolm.


Malcolm's Amazon Wishlist:
http://www.amazon.com/gp/registry/registry.html?ie=UTF8&type=wishlist&id=1VB5A16R2KV0T