---
url: "https://vueda.dev/v3/reference/api/py/vueda.core.models/FormattedNameBaseModel.md"
title: "FormattedNameBaseModel"
---

# 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` {#Meta}

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

### Source {#Meta-source}

`server/vueda/core/models.py:330`

## `check` {#check}

Django's model checks plus the manager checks ``vueda_core.E019`` and ``vueda_core.E020``,
and the base-manager check ``vueda_core.E017``.

Hooked here rather than inside ``_check_ordering`` because they 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. The model's managers matter whatever the ordering says,
because filtering or ordering by ``formatted_name`` anywhere needs their annotation.

Django runs model checks on every installed model, once each, so ``vueda_core.E019``
reaches a model whether or not anything registered it.

``vueda_core.E019`` is reported beside ``models.E015``, since the two name different faults:
a term the model does not have, and a manager that does not supply it. An ordering Django
already rejects is otherwise left at that. The base manager is not the fault ``models.E015``
names, so fixing the term and running the checks again is what surfaces
``vueda_core.E017`` if the model is also in that state.

### Signature {#check-signature}

`check(cls, kwargs)`

#### Parameters {#check-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| cls |  | yes |  |  |
| <span id="check-param-kwargs">kwargs</span> |  | no |  |  |

### Source {#check-source}

`server/vueda/core/models.py:430`

## `formatted_name` {#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-signature}

`formatted_name(unknown)`

#### Parameters {#formatted_name-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="formatted_name-param-unknown">unknown</span> |  | yes |  |  |

## `objects` {#objects}

### Signature {#objects-signature}

`objects(unknown)`

#### Parameters {#objects-parameters}

| Name | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| <span id="objects-param-unknown">unknown</span> |  | yes |  |  |

## `formatted_name_lookup_expression` {#formatted_name_lookup_expression}

A lookup path, such as ``"customer__name"``, that gives this model's formatted name.

Declare it with ``formatted_name = None`` to name a column on this model or one reached through
single-valued relations. ``FormattedNameManager`` annotates ``formatted_name`` from it.

A model that declares a lookup expression may name its own ``formatted_name`` in
``Meta.ordering``. Django's ``models.E015`` check resolves ordering terms against the model's
fields, so VUEDA withholds that one term from the check. The check tests every other term as
usual. VUEDA withholds the term only when the default manager annotates ``formatted_name``.
``Meta.ordering`` applies to every queryset, including those that a management command, a data
migration, or the admin builds, and only the manager's annotation makes the term valid there.
With any other default manager, ``models.E015`` reports the term, and ``vueda_core.E019`` also
reports the manager. A related path such as ``customer__formatted_name``
is never withheld. ``FormattedNameManager`` describes Django's base manager, whose querysets its
annotation does not reach.

## `formatted_name_select_related` {#formatted_name_select_related}

Relation paths to join whenever this model is queried, for a ``get_formatted_name()`` that reads them.

``annotate_formatted_name`` passes them to ``select_related()``, so the method's relations load in
the same query instead of one extra query per row.

## Source

`server/vueda/core/models.py:290`