carljm/django-model-utils — pull request #91 by kezabelle (2013-11-02 14:57:00+00:00)
Title: InheritanceManager get_subclass may be clobbering previous select_subclasses 

This is *not merge ready*, and is a sketch of something I *think* is an issue.

Basically, given something like:
```
qs = MyModel.objects.all().select_subclasses('only_one_type')
# lots of other code between the original qs and the call to get_subclass
if not request.user.is_superuser:
qs = qs.filter(is_published=True)
qs = qs.exclude(some_thing=1)
# and so on ... imagine we've paged the original qs out of viewport.
# we don't know what qs contains, we just trust it to return the
# correct thing.
obj = qs.get_subclass(pk=kwargs['pk'])
```

The expectation I'd have is that `obj` is of whatever `only_one_type` yields down to, even if, say, there's `only_one_type__subclass` further down the inheritance chain, because that's what was requested.

As it stands, the `get_subclass` method on the InheritanceQuerySet does a bare `select_subclasses` assuming that it needs to do so - this also means that given a parent model with a lot of subclasses, it does `LEFT OUTER JOIN` for each one, even if you've asked for only a subset to be joined.

The pull request is intended to change that so that the `get_subclass` method inspects `self` for a `subclasses` attr, in the same way the iterator itself does.

**However**, the tests as I've committed them are not usefully functional in demonstrating the problem at hand, with the exception of `test_get_subclass_unrelated_instance` - the very nature of the problem (a bare `select_subclasses` replacing any previous) means the others pass, and I can't currently think of a clear and non-convoluted way of inspecting the `subclasses` attr on the queryset, because it's not a queryset we're getting back, but an individual downcast object.

As such, I'm opening this PR by way of discussing whether we think it's a problem, and how it can be tested reasonably.