Abstract models and the app registry

[Alexander Hill]

Hi all,

I'm looking for some background about abstract models, specifically why they aren't registered with the app registry as normal models are.

For some context, I'm working on a ticket [0] to refactor Django's lazy model operations (used e.g. to resolve string references in related fields). To acquire an actual model class from an "app_label.ModelName" string, we use Apps.get_registered_model. However, as far as that method is concerned, abstract models don't exist, so operations that wait on them are never run.

It also means abstract models clutter the pending operations dict, making it impossible to provide a good warning when there's a typo in a string model reference, for example.

Fortunately this doesn't matter too much in practise, because concrete subclasses work fine despite related fields not being hooked up right on an abstract parent.

[0] https://code.djangoproject.com/ticket/24215

Cheers,

Alex

[Carl Meyer]

Hi Alex,

Django treats abstract models as simply a convenient way to group some
fields and Python-level behavior; they aren't real models in any sense
(they have no db table, you can't query on them, you can't get them from
the app registry, etc.) It sounds like the behavior you're describing is
mostly consistent with that, except for the "clutter the pending
operations dict" part. I would think that ideally abstract models should
never appear in the pending operations dict at all in the first place,
and any warning regarding a typo in a string model reference should be
fired based on a concrete subclass, not based on the abstract base
itself. Is there a problem with that approach? (It's been a long time
since I looked at that code in detail.)

Carl

[Alex Hill]

Hi Carl,

Thanks for getting back to me. That all makes sense.

I'm still curious as to why abstracts aren't registered – is that a requirement of some feature of the app registry design, or is it just that way because?

I think what I would like to do is just declare that string references in related fields are only resolved in concrete models. In abstract models, they can just remain as string references until the fields are copied and contributed to concrete subclasses, at which point they'll be resolved normally. Then if abstract models do end up in lazy operations, they can be considered an anomaly just as a typo would be; we don't need to account for them specifically.

Can you see any problem with that approach?

I've just implemented that change and the test suite passes – not surprising given that there were edge cases where this was happening anyway (e.g. abstract models with relations to "self").

Cheers,

Alex

[Carl Meyer]

On 02/11/2015 08:17 PM, Alex Hill wrote:
> I'm still curious as to why abstracts aren't registered – is that a
> requirement of some feature of the app registry design, or is it just
> that way because?

I think it's just a natural consequence of not considering them to be
real models.

One practical issue is that currently abstract models are not required
to be in an app or have an app-label / app-config at all, which I know
people take advantage of (because when we temporarily broke it after the
merge of app-loading, people complained); it would be hard to keep this
working and also add abstract models to the app-registry.

> I think what I would like to do is just declare that string references
> in related fields are only resolved in concrete models. In abstract
> models, they can just remain as string references until the fields are
> copied and contributed to concrete subclasses, at which point they'll be
> resolved normally. Then if abstract models do end up in lazy operations,
> they can be considered an anomaly just as a typo would be; we don't need
> to account for them specifically.
>
> Can you see any problem with that approach?

That seems fine to me. I don't think anyone should be trying to do
anything with relation fields on an abstract model. In fact, I've never
seen anyone try to do anything at all with an abstract model other than
inherit from it.

> I've just implemented that change and the test suite passes – not
> surprising given that there were edge cases where this was happening
> anyway (e.g. abstract models with relations to "self").

Carl