#21699: Provide a way to define a model without being registered into AppConfig
------------------------------+--------------------------------------
Reporter: mitar | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
Keywords: app-loading | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Comment (by mitar):
I am just copying from #21698, to make things more clear here. So my
comment how I see that unregistering could help:
> So there are two ways to allow making custom subclasses of models which
should not be registered. One is to somehow allow some configuration in
Meta (#21682), another is to call current metaclass which adds it, but be
able to remove it from registry immediately afterwards (a bad side-effect
is that registration signal has been already made).
I didn't know about "no-op subclass" approach. This seems interesting
idea.
> Maybe the goal is to avoid leaking memory when creating a large number
of such models?
Yes. So what we are doing is developing support for dynamic schema. Users
can add dynamically fields from the many hop away models. In a way we make
proxy fields to things you would need multiple hops and we do one big join
instead in the background to not have to fetch them again and again as you
are hopping around. (Those hops can cross content type relations as well.)
(Which mean you can change concrete implementation of a model, but the
rest of your code can still work as it is referencing them through
registered names.) We add those fields as virtual fields into base model
and create a dummy proxy model to keep them, when we return a new queryset
for them. So the syntax is something like:
{{{
queryset = models.Node.objects.regpoint('config').registry_fields(
name='core.general#name',
type='core.type#type',
router_id='core.routerid#router_id',
project='core.project#project.name',
).regpoint('monitoring').registry_fields(
last_seen='core.general#last_seen',
network_status='core.status#network',
monitored_status='core.status#monitored',
health_status='core.status#health',
peers='network.routing.topology#link_count',
).order_by('type')
}}}
So, after you fetch those additional fields, returned queryset contains a
dynamically created proxy model to `models.Node`, with `name` and others
added as virtual fields. As this proxy model is useful only for this
particular queryset, we do not want to register it globally. `core.status`
is a registered name for a particular registry point, which can be
implemented by any model which announces that it is implementing it. So a
concrete related model can change (be extended by an app), but your
queryset does not have to change.
All this is a bit involved and we do not yet have good documentation, but
you can check [https://dev.wlan-si.net/wiki/Nodewatcher/Registry this
description] and our
[https://github.com/wlanslovenija/nodewatcher/blob/77ec018255fa0546b362376976db2f7b874968c1/nodewatcher/core/registry/lookup.py#L138
current implantation of creating a dynamic proxy model and unregistered
immediately afterwards is here]. We do not want that such models pile up.
I know this is not public API, but it would still be good to have some
clear way to: or not register a model when created, or be able to remove
it from the registry. As you are planing on rewriting AppConfig, I just
wanted to raise a point that some internal API (which I understand can
change at any time) would be useful here.
--
Ticket URL: <https://code.djangoproject.com/ticket/21699#comment:6>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.4ef60c8fb6bc948ce10322775fd614e9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
