#24231: Regression in availability of `_meta.get_field()` before app registry is
fully populated
-------------------------------------+-------------------------------------
     Reporter:  carljm               |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  1.7
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Description changed by carljm:

Old description:

> In Django versions prior to 1.8, it was possible to call
> `_meta.get_field(...)` on a model class before the app registry was fully
> populated -- for instance, in a `class_prepared` signal handler that
> adjusts a model's fields or adds new field(s). (Real-world example:
> https://github.com/carljm/django-model-
> utils/blob/master/model_utils/models.py#L54-L94)
>
> In 1.8, with the meta refactor, this now raises an `AppRegistryError`.
>
> This change makes sense, because `get_field` also gets reverse related
> fields, and those can't be populated until all models are done loading.
> But it's still a regression in a reasonable use case (even though the
> meta API was technically private before, it was de facto public).
>
> I think the issue of "when are these methods safe to call?" should be
> discussed in the _meta refactor porting guide, because it has changed
> from 1.7, even for methods like `get_field()` that otherwise remain
> similar.
>
> I also think there should be some public supported, documented API that
> is safe to use before the app registry is populated, that accesses only
> fields declared on the local model. Perhaps an API equivalent to what you
> can currently do with `_meta._get_fields(reverse=True)`. (I note that
> this last is already used several places in Django internally where local
> fields need to be accessed before the app registry is ready.)

New description:

 In Django versions prior to 1.8, it was possible to call
 `_meta.get_field(...)` on a model class before the app registry was fully
 populated -- for instance, in a `class_prepared` signal handler that
 adjusts a model's fields or adds new field(s). (Real-world example:
 https://github.com/carljm/django-model-
 utils/blob/master/model_utils/models.py#L54-L94)

 In 1.8, with the meta refactor, this now raises an `AppRegistryError`.

 This change makes sense, because `get_field` also gets reverse related
 fields, and those can't be populated until all models are done loading.
 But it's still a regression in a reasonable use case (even though the meta
 API was technically private before, it was de facto public).

 I think the issue of "when are these methods safe to call?" should be
 discussed in the _meta refactor porting guide, because it has changed from
 1.7, even for methods like `get_field()` that otherwise remain similar.

 I also think there should be some public supported, documented API that is
 safe to use before the app registry is populated, that accesses only
 fields declared on the local model. Perhaps an API equivalent to what you
 can currently do with `_meta._get_fields(reverse=False)`. (I note that
 this last is already used several places in Django internally where local
 fields need to be accessed before the app registry is ready.)

--

--
Ticket URL: <https://code.djangoproject.com/ticket/24231#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" 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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.8991cefc4bef401a7cbabadd32df767d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to