In Django, which Meta options does a child model inherit from an abstract base class, and which from a multi-table parent?

## Two rules, because two different things are inherited A Django model's inner **`Meta`** class holds table-level options: `ordering`, `db_table`, `indexes`, `constraints`, `get_latest_by`, `verbose_name` and others. When models inherit, Django applies **different rules** depending on whether the parent exists in the database: | Parent kind | Does the child get the parent's `Meta`? | What carries over | |---|---|---| | **Abstract base** (`abstract = True`) | yes, if the child declares no `Meta` | every option, with `abstract` reset to `False` | | **Multi-table parent** (concrete) | no | only `ordering` and `get_latest_by`, if the child sets neither | | **Proxy's parent** | no | same as multi-table: `ordering` and `get_latest_by` | The reason: an abstract base never became a table, so its options have not been applied anywhere yet and are meant for the children. A concrete parent's options have already been applied to the parent's own table; re-applying them to the child would usually contradict them. ## Abstract bases: handed down and extensible If a child of an abstract base declares no `Meta`, it simply gets the base's. To add to it, the child subclasses it: ```python class FleetRecord(models.Model): created_at = models.DateTimeField(auto_now_add=True) class Meta: abstract = True ordering = ["-created_at"] get_latest_by = "created_at" class Car(FleetRecord): plate = models.CharField(max_length=12, unique=True) class Meta(FleetRecord.Meta): db_table = "fleet_cars" ``` Points that trip people up: - **`abstract` is reset.** Before installing the inherited `Meta`, Django sets `abstract=False`, so `Car` is concrete. An abstract chain needs `abstract = True` re-declared on each abstract level. - **A child `Meta` that does not subclass replaces.** If `Car` wrote a plain `class Meta:` with only `db_table`, it would lose the base's `ordering` and `get_latest_by`. - **Multiple abstract bases.** Python's attribute lookup finds `Meta` on the first base only; to combine two, write `class Meta(FirstBase.Meta, SecondBase.Meta):`. ## Options that misbehave when inherited from an abstract base Some options name something that must be unique per table: 1. **`db_table`** — every child that inherits it would map to the same table, which is almost never intended. 2. **`indexes` and `constraints`** — index and constraint names must be unique, so a fixed name repeats in every child; write `name="%(app_label)s_%(class)s_plate_idx"`, which Django fills with the child's lowercased app label and class name. ## Multi-table and proxy children: only two options travel A multi-table child cannot see its parent's `Meta` at all. The only behaviour it inherits is: - **`ordering`**, when the child does not declare its own; - **`get_latest_by`**, when the child does not declare its own. So a `Vehicle` ordered by `plate` makes `Van.objects.all()` ordered by `plate` too, which can surprise someone reading `Van` alone. To remove it, the child declares `ordering = []`. Everything else — `verbose_name`, `indexes`, `constraints`, `permissions`, `db_table` — must be declared on the child if the child needs it. Proxy models inherit `Meta` the same way, which is why `ElectricCar(Car)` can set its own `ordering` while silently keeping `Car`'s `get_latest_by`, if `Car` declares one. ## Checking what a model actually got When a hierarchy is several levels deep, reading the source is slower than asking Django. The model `_meta` API exposes the resolved options on every class: - `Van._meta.ordering` — the ordering in force, whether declared or inherited from `Vehicle`; - `Van._meta.get_latest_by` — the field `latest()` and `earliest()` use when called without arguments; - `Car._meta.db_table` — the table name, which exposes a `db_table` accidentally inherited from an abstract base; - `Car._meta.abstract` — `False` on every concrete child, confirming the automatic reset. A short test that asserts these values for each model in a hierarchy catches the silent cases: a child `Meta` that replaced the base's instead of extending it, or a parent ordering that started applying to every child query after someone added it to the parent. Such a test fails at the moment of the change instead of months later in a slow, unexpectedly sorted admin list. ## How to answer in an interview State the two rules and the reason: abstract options are meant for children; concrete options already belong to a table. Then name the traps — the `abstract` reset, replacing instead of subclassing, the first-base-wins lookup, and placeholder names for indexes and constraints.