When a mapped class declares nothing about a column, what defaults apply, and why is that risky over time?

Every mapping has two parts: what was written down, and what was filled in. The second part is larger than most teams realise, and it is where long-lived schemas accumulate decisions nobody made. ## What gets decided when nothing is declared - **Whether a member is mapped at all.** Layers differ on the default: some map every readable and writable member unless it is explicitly marked as not persisted (opt-out), others map only members that carry a declaration (opt-in). Under opt-out, adding a member to a class adds a column to the schema. Under opt-in, adding a member persists nothing and the omission is silent until someone notices data going missing. - **Nullability.** Some layers infer it from whether the member's type admits absence; others default everything to permitting null because that is the safe choice for a column being added to an existing table. - **Text length.** A textual column needs a size, and something picks one when nobody does. The number chosen is arbitrary from the domain's point of view and generous or stingy by accident. - **Numeric precision and scale.** A decimal column needs both. A default scale that is too small silently rounds monetary values; a default precision that is too small rejects large ones. - **The identifier itself.** The derived table or column name is a default like any other. - **Fetch and ordering defaults** for associations and collections, which belong to their own mapping concerns but arrive through the same silence. ## Where the default lands | How the schema is produced | Where the default ends up | Failure mode | |---|---|---| | Generated from the model | Directly in the shipped schema | A wrong default becomes a real column that later needs a migration | | Authored by hand, model validated against it | In the layer's expectations | Mismatch is caught at startup if validation is on, and at query time if it is not | | Authored by hand, no validation | Nowhere visible | The layer assumes one thing, the database holds another, and reads or writes fail on the unlucky row | ## The reading problem The deeper issue is not that a default is wrong — most defaults are reasonable. It is that a default and a decision are indistinguishable in the source. Consider a column that permits absence. It might be that way because absence is a real domain state, or because nobody said otherwise. A year later, someone deciding whether to make it required has to reconstruct which it was, and the code offers no evidence either way. The same ambiguity applies to a text length, a scale on a money amount, and whether a member is persisted at all. This is why defaults become decisions: not through a single bad choice, but through the accumulation of choices that were never examined and can no longer be distinguished from choices that were. ## Practices that keep it honest 1. **Declare intent on load-bearing elements even when it matches the default.** Stating that a column is required, or that a money amount has a specific scale, costs one line and converts an assumption into a documented decision. 2. **Turn on startup validation of the resolved mapping against the real schema.** It converts a silent divergence into a boot failure, which is the cheapest place to find one. 3. **Review generated schema output before it ships**, if the schema is generated. Reading the definition the layer produced is the only way to see the defaults it chose. 4. **Make the opt-in versus opt-out rule an explicit team convention**, so nobody has to guess whether adding a member adds a column. 5. **Keep a check on the members you deliberately do not persist**, because under an opt-out default a new computed member becomes a column, and under opt-in a new stored member becomes nothing. ## Where this bites in production The expensive cases share a pattern: the default was harmless when the table was small and became structural later. A generously sized text column costs nothing on ten thousand rows and matters on a hundred million. A decimal scale chosen by default rounds cents in a way that only appears in a reconciliation report. A column left nullable because nobody said otherwise accumulates rows with absent values, and by the time someone wants to make it required, backfilling is a project rather than a migration. None of these is a bug in the layer; each is an unexamined default that hardened into a fact. ## What a strong answer sounds like Name several things that get defaulted, distinguish opt-in from opt-out mapping, and then move to the real point: the reader cannot separate a default from a decision, so declare the ones that carry weight and validate the rest at startup. Mentioning that a wrong default in a generated schema turns into a migration, while a wrong default against a hand-authored schema turns into a startup or query failure, shows you have operated both arrangements.