django 1.8 compatibility in the db module

[kavdev]

It'd also be great if this was released to PyPI. The version on there is still behind.

[kavdev]

So, django.db.models.query.iterator now fetches an initial query via compiler.execute_sql(). Since iterator is not overridden in djangotoolbox, a select request now gets sent to the base compiler which has historically only expected count queries. Ideally, select logic should be in the base compiler's execute_sql() method, but this is not the case. In the new flow, that initial query sent to execute_sql() returns None and results_iter is called to handle the query as usual.

results_iter now has a results parameter which defaults to None. If it's None, the query is evaluated. In django 1.8's compiler code, that parameter is part of some kind of caching mechanism that I didn't look into.

[aburgel]

with this patch, do any of the nonrel db backends support 1.8?

[kavdev]

Are you asking whether or not other nonrel backends will automatically work because of this patch?

That depends on how much they've overwritten. Most of the changes are in the execute_sql methods of each compiler.

Here's a quick list of changes/compatibility guide:

Public API

• Add self.pre_sql_setup() at the top of the execute_sql() method of each compiler. This should have been called in previous versions, but this is the first time it's actually necessary for nonrel stuff.
• Add results=None as a default parameter to theresults_iter() signature.
• Aggregate imports and attributes moved/were renamed. See the new NonrelCompiler.execute_sql() method for info on how to fix issues that arise from this.
• connection.use_debug_cursor is now connection.force_debug_cursor. According to the patch's author, it should now only return a binary, not tertiary, boolean (True/False vs True/FalseNone).

Private API

• django 1.8 supports multiple converters, so calling query.convert_values() no longer works. You'll have to either learn the new get_converters() API or just use self.connection.ops.convert_values(). The latter is backwards-compatible.
• _decode_child fixes

[aburgel]

Thanks for the explanation. I'm mostly curious because these changes can't be used unless you've also got the corresponding changes to the backends. Are you also working on those? For which backends?

[kavdev]

I mean I'd assume the maintainers would update their packages if updating this dependency. If this is a no go, I'll just create a 1.8+ fork.

[aburgel]

Not a no-go. This is definitely good stuff. Just curious how you're planning to use it.

[kavdev]

Ah, gotcha. I maintain django-ewiz, which uses djangotoolbox as a template.