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 On Thursday, February 12, 2015 at 2:49:34 AM UTC+8, Carl Meyer wrote: > > Hi Alex, > > On 02/11/2015 11:39 AM, Alexander Hill wrote: > > 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 > > 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 > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5904c936-b06e-4a72-a181-e243f1891e7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
