FormattedNameBaseModel

Overview

Shared base of every VUEDA model base, and the set that carries class Vueda policy.

VuedaModel and Lookup are siblings rather than parent and child, so feature policy keys off this base to reach both.

Meta

Default Django Meta base that replaces Django's add/change/view/delete permissions with CRUDL names.

Source

server/vueda/core/models.py:169

_check_ordering

Django's own ordering checks, minus the formatted_name term Django cannot resolve.

A model whose formatted name comes from formatted_name_lookup_expression has no formatted_name column, and Django's models.E015 resolves the names in Meta.ordering against the model's own fields. It would reject ordering = ["formatted_name"] on such a model even though the ordering is valid: FormattedNameManager annotates the lookup expression under that name onto every queryset the model builds, and the database sorts the annotation.

The manager is what makes withholding the term safe, so the manager is what this asks about. Meta.ordering applies to every queryset of the model, not just the ones a viewset builds, so suppressing models.E015 on a model whose default manager doesn't annotate would trade a startup error for a FieldError at query time on any path that didn't go through VuedaViewSet.get_queryset. Such a model is left to models.E015, which is right about it: there really is no formatted_name to order by. vueda_info.E009 reports the same model with a hint aimed at the manager rather than at the ordering, but it is a second opinion rather than the thing that makes this sound — it only reaches registered models, while Meta.ordering breaks queries whether or not anything registered the model.

formatted_name_annotation_path is the single rule behind every formatted_name annotation VUEDA adds, so asking it rather than reading the lookup expression directly keeps this in step with what the manager will actually do. It answers None for a model that declares a lookup expression and keeps a formatted_name column, which is annotated by nothing and needs no suppression: the column is a real field, so models.E015 resolves the term on its own.

Model._base_manager is the one path the manager doesn't cover, since Django builds that one itself as a plain models.Manager. Evaluating a base-manager queryset that keeps this ordering raises FieldError, so withholding the term without asking about that manager too would hide a second failure behind the first: _formatted_name_base_manager_errors reports it as vueda_core.E017. See the note at the end of FormattedNameManager for which callers reach such a queryset and why almost none do.

Only that term is withheld, and only on a model that has a lookup expression to reach it through. Every other term is still Django's to check, including a formatted_name on a model that resolves it in Python with get_formatted_name() — nothing annotates that one, so models.E015 is right to reject it, and vueda_info.E005 explains why.

Signature

_check_ordering(cls)

Parameters

Name	Type	Required	Description
cls		yes

Source

server/vueda/core/models.py:193

_formatted_name_base_manager_errors

Report a base manager that cannot compile the ordering the model declares.

FormattedNameManager annotates formatted_name onto the querysets the model itself builds, so a Meta.ordering naming it sorts on the annotation. Django builds Model._base_manager itself, as a plain models.Manager, unless Meta.base_manager_name names one, so that queryset carries the ordering with nothing to sort and raises FieldError the moment it compiles.

Almost nothing evaluates a base-manager queryset whole. get() clears ordering, which covers refresh_from_db and dereferencing a foreign key, and select_related and prefetch_related order by nothing of the related model's own. A cascade delete does: Collector.related_objects hands back a plain _base_manager queryset, and Collector.collect evaluates it whenever can_fast_delete said no, which a related model with cascading children of its own, a parent link, or a delete signal receiver all say. Deleting the parent then fails with a FieldError naming a field nobody wrote.

Both managers are asked by compiling, not by reading their classes. A project's own manager that annotates the path is a base manager this model can use, whatever it inherits, and a FormattedNameManager subclass whose get_queryset dropped the annotation is not. The default manager is asked second, and its answer is what keeps this from reporting an ordering that is simply broken: when the ordering doesn't compile there either, the ordering is the fault, and models.E015 or vueda_info.E009 names it with the fix it deserves.

_base_manager is read rather than Meta.base_manager_name, because Django resolves that name up the MRO before building a manager of its own. A base manager an abstract parent selected counts as much as one this model names.

Signature

_formatted_name_base_manager_errors(cls)

Parameters

Name	Type	Required	Description
cls		yes

Source

server/vueda/core/models.py:280

_get_formatted_name

Signature

_get_formatted_name(self)

Parameters

Name	Type	Required	Description
self		yes

Source

server/vueda/core/models.py:172

_has_formatted_name_field

Signature

_has_formatted_name_field(cls)

Parameters

Name	Type	Required	Description
cls		yes

Source

server/vueda/core/models.py:186

check

Django's model checks plus the base-manager check vueda_core.E017.

Hooked here rather than inside _check_ordering because the two answer different questions. _check_ordering withholds a term Django would misjudge, so it only runs where a term names formatted_name outright. The base manager fails on any ordering that needs the annotation, including one that names it only inside a Case(When(...)) condition, and that ordering withholds nothing.

An ordering Django already rejects is left at one message. models.E015 means the terms name something the model does not have, which is one fault with one fix, and the base manager is not it. Fixing the term and running the checks again is what surfaces vueda_core.E017 if the model is also in that state.

Signature

check(cls, kwargs)

Parameters

Name	Type	Required	Description
cls		yes
kwargs		yes

Source

server/vueda/core/models.py:258

formatted_name

A wrapper for a deferred-loading field. When the value is read from this object the first time, the query is executed.

Signature

formatted_name(unknown)

Parameters

Name	Type	Required	Description
unknown		yes

objects

Signature

objects(unknown)

Parameters

Name	Type	Required	Description
unknown		yes

_meta

Source

server/vueda/core/models.py:154