select_related() uses always QuerySet and Query classes from originating Model

[Jani Tiainen]

When having two models:

class ModelNormal(models.Model):
    geo = models.ForeignKey('ModelGeo')

class ModelGeo(models.Model):
    geom = models.PointField()
    objects = models.GeoManager()

When querying:

ModelNormal.objects.all().select_related()

Accessing objects causes traceback because Django used Manager instead of GeoManager for GeoModel instance(s).

Further investigation indicated that QSL queries didn't have any decorators that GeoManager does for geometry fields needed in Oracle.

[Jani Tiainen]

When you have models just like in description and both have different, custom QuerySet containing managers using .select_related() fails.

This is because Django assumes that all related models uses same QuerySet (and Query) as originating table, in case of example ModelNormal.

This is most visible with GeoDjango models since many of them uses custom decorations to produce WKT text from spatial column and trying to use normal, nongeomodel as a originating model and .select_related() fails with exceptions.

Note:

In multidb branch this appears to be problem of sql compiler that expects that all related models uses same compiler as originating model. Which for example in GeoDjango models case is not true - they have their own compiler that adds spatial field decorations to queries causing different errors on different spatial backends.

[Jani Tiainen]

Since multidb landed on trunk I update this ticket:

When using custom SQLCompiler that overrides get_columns code to mangle column selects instead of just getting fields as they are doesn't work with Django when using select_related() queryset method.

select_related() always uses it's own Manager SQLCompiler to construct SQL needed to query fields. (code that generates SQL for related fields is in django/trunk/django/db/models/sql/compiler.py around line 209). For example contributed gis application uses it's own thus creating it impossible to mix non-geo and geomodels.

Each related field should produce SQL using their own SQLCompiler instead of using originating model SQLCompiler which will produce incorrect SQL.

[Jani Tiainen]

Sample case when select_related() fails to use custom compiler

[jbronn]

(In [12022]) Fixed #12344 -- Using select_related() on geographic fields with the Oracle spatial backend now works.

[jbronn]

(In [12023]) [1.1.X] Fixed #12344 -- Using select_related() on geographic fields with the Oracle spatial backend now works.

Backport of r12022 from trunk.