Thanks for the review, Jeremy. On Tue, Dec 15, 2009 at 5:31 PM, Jeremy Dunck <[email protected]> wrote: > This bit doesn't seem to be true; It seems that missing fields will > raise InsuficientFields instead. Am I reading it wrong?
Ah, good catch. I'd intended to remove this behavior as it's overly strict -- the whole point of ``raw()`` is that it lets you play fast and loose with best practices. The code now matches the docs. > RawQuery._populate_cache does fetchall(). This is sort of surprising, > since normal QuerySets go out of their way to avoid fetchall. > RawQuerySets are not as lazy as normal querysets in that normal > querysets do fetchmany. If this was intended, it might be worth > pointing out. In fact, I think RawQuerySet.iterator won't do what > people expect. Yeah, this is annoying: SQLite doesn't support cursor.rowcount until all the rows have been fetched, so supporting a cheap __len__ is hard. After thinking about it for a while I've decided just to ditch __len__ and return the raw cursor for __iter__. That's closer to the "raw" database access anyway. Users can always ``len(list(q))`` if they must. Nothing in the docs mentioned len() any way, and I can't see it being all that useful -- as long as you're writing raw SQL, COUNT(*) is going to be more efficient anyway. > On "admonition:: Model table names" - Person._meta.db_table would have > the value, and it might be better to be more explicit about it. But > it's an "_" API, so maybe we don't want to make it clearer after all. > ;-) I'm leaving it out deliberately -- we've avoided stabilizing _meta (so far), so until we do (or add an official model reflection API) I'm leaving it out of the docs. > "You'll use ``%s``" > Is that back-end independent? It looks like it gets evaluated by > whatever backend you're using, and so would depend on DB-API > paramstyle. Nope -- ``connection.cursor()`` returns a ``CursorWrapper`` that translates query styles into '%s' reguardless (see django.db.backends.sqlite3.SQLiteCursorWrapper for one example). > RawQuery.validate_sql excludes anything but selects, but Oracle uses > comments to do query hinting. *** boggles *** (Looks like it's not a problem, though.) ---- New patch uploaded - let me know if you see anything else. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
