When a data-access layer builds the schema from its mapping, what do its re-create, auto-alter, validate-only and none modes do?
answer
- four levels of intrusiveness
- two modes write, two only look
- drop-and-rebuild versus add-in-place
- validate compares, then refuses to boot
- deployed schema belongs to scripts
basics
~20 sSchema-from-mapping modes differ in how far the layer will change the database: re-create drops and rebuilds the mapped tables, auto-alter adds what is missing in place, validate-only compares and refuses to start on a mismatch, and none touches nothing.
solid answer
~40 sA mapping already describes tables, columns, types and keys, so most data-access layers can emit the `CREATE TABLE` statements for it. The modes differ by how destructive they are. **Re-create** drops the mapped objects and builds them again at every startup, so all their rows are lost — it suits a disposable local or test database. **Auto-alter** compares mapping to schema and applies the missing pieces in place; it is typically additive, adding tables, columns and indexes rather than removing or narrowing them. **Validate-only** performs the same comparison, changes nothing, and aborts startup when the two disagree. **None** does no comparison and no change. In deployed environments the schema is normally owned by reviewed migration scripts, and the layer runs in validate-only or none.
go deeper
Learn the four names and what each one does to the data: rebuild, add in place, only check, do nothing. Knowing which of them destroys rows is the point of the question.
Explain why an additive mode still accumulates drift: it adds what is missing but does not remove what the mapping abandoned, so the two shapes diverge in the direction the tool cannot repair.
Say where each mode sits in your pipeline and why the deployed schema is owned by reviewed scripts, with the layer reduced to a comparison that fails startup instead of a generator that writes.
Frame it as a control question: generation moves schema authority into whichever process starts first, with no review, no record and no ordering. That is the tradeoff to argue, not the convenience.
## What "schema from the mapping" means A mapping already carries almost everything a `CREATE TABLE` statement needs: which class maps to which table, which field to which column, the declared types and lengths, which field is the key, which associations imply a foreign key, and which fields must be unique. Because that information is machine-readable, most data-access layers can turn it around and **emit the schema instead of reading it**. The question every project has to answer is not whether the layer *can* do that, but **how much of the deployed database it is allowed to touch**, and that is what the modes express. Treat them as a ladder of intrusiveness rather than four unrelated options. ## The four modes | Mode | What it does at startup | Effect on stored rows | Where it belongs | |---|---|---|---| | **Re-create** | Drops the mapped objects and creates them again from the mapping | Everything in those tables is gone | A disposable local database, or a fresh database per test run | | **Auto-alter** | Compares, then applies missing pieces in place — typically additive | Rows survive; new columns arrive empty or defaulted | Local experimentation only; not a deployed environment | | **Validate-only** | Compares and reports; changes nothing; aborts startup on a mismatch | None | Deployed environments, as a drift gate | | **None** | No comparison and no change | None | Deployed environments where something else does the checking | Two of these write to the database and two do not, and that is the line that matters. Re-create and auto-alter are **generators**; validate-only and none are **passive**. ## Why the additive mode is not the safe middle ground Auto-alter looks like a compromise — it keeps your data and quietly fixes what is missing — and that impression is why it causes incidents. - **Nothing was reviewed.** The statements are computed at process start and executed immediately. No one read them, and nothing about the change was agreed before it ran. - **It only moves in one direction.** Because it typically adds rather than removes or narrows, everything the mapping stopped using stays behind: dead columns, stale indexes, constraints nobody wants. Drift accumulates precisely where the mode cannot clean it up. - **Names are invented.** Constraints and indexes it creates get generated names, so the deployed database ends up with objects nobody can refer to reliably later. - **Timing is whatever the process does.** The change runs when the application happens to start, with no consideration of table size or of traffic already hitting that table. - **Several instances may try at once.** When a deployment starts many copies of a service together, each one independently decides the schema needs altering. - **No record survives.** Afterwards there is no artifact saying what ran, so two environments can differ with nothing to compare. Re-create is more obviously dangerous and therefore, oddly, safer: nobody mistakes "drops every table" for something to leave enabled. ## Validate-only and none Validate-only is the mode most deployed services want. It performs the same structural comparison the generator would, then **refuses to start** rather than repairing anything. Its value is that a schema problem becomes one loud failure at startup instead of a confusing error the first time some rarely used query runs. Its limit is equally important: it checks **structure the mapping knows about**, not whether the stored data suits the new shape, and typically it does not object to extra columns the mapping never mentions. None is the honest choice when a separate gate already covers the same ground, or when the mapping deliberately describes only part of a larger shared database. ## The usual environment gradient 1. **Laptop / unit tests** — re-create against a throwaway database, because rebuilding from the mapping is faster than maintaining fixtures. 2. **Shared development or integration** — scripts, so the environment behaves like the real one. 3. **Staging and production** — reviewed migration scripts own the schema outright; the layer runs validate-only or none. ## What none of the modes do No mode moves data. Generation emits structure — tables, columns, keys, indexes — and never the statements that populate a new column or reshape existing values; designing that work is a separate concern. A generated schema also cannot express what the mapping does not model, such as storage options, partitioning or specialised index shapes. And a passing validation is not a guarantee that the rows in those tables are meaningful — only that the structure the mapping requires exists.
- Why is re-create acceptable for tests but auto-alter is not acceptable anywhere deployed?Re-create is used against a database whose contents are worthless and rebuilt on purpose, so its destructiveness is the feature. Auto-alter is used against a database whose contents matter, applies statements nobody reviewed at whatever moment a process starts, and leaves no artifact describing what it did.
- If the schema is owned by scripts, is there still a reason to keep the generator around?Yes, as an authoring aid and a check. The generator can produce a first draft of a change for a human to review and edit, and the same comparison logic, run in validate-only mode, tells you whether the mapping and the schema still agree.
saying these in an interview costs you the question
- Says auto-alter is fine in production because it never drops anything
- Thinks re-create preserves the rows already stored
- Believes validate-only repairs the mismatch it reports
- Expects the additive mode to remove columns the mapping no longer maps
- Treats a passing structural check as proof the stored data fits