Before reshaping a column, how do you find every query that touches it under mixed authoring styles?

## Why the inventory is the hard part Reshaping a column - renaming it, splitting it, narrowing its type, making it nullable - is a small change to the schema and an unbounded change to the code, because the code that depends on that column is spread across however many queries touch it. The migration is not the risk. **Finding every query** is the risk, and how hard that is depends almost entirely on the authoring styles in use. ## What each style gives you to search with | Where the query lives | How you enumerate uses of a column | How reliable it is | |---|---|---| | Typed DSL generated from the schema | Regenerate, then compile; or use the symbol's call hierarchy | **Complete** for anything that compiles | | Query declared by name in one registry | Read the registry, or let the boot parse it | Complete for what is declared | | Method-name-derived finder | Text-search the field token inside method names | Good - the name is literal, so it is findable | | Object-level query string in one place | Text-search the field name | Fair - depends on the string being literal | | Text assembled from fragments at request time | Nothing static finds it | **Poor** - the full text exists only at runtime | The pattern is that **an inventory is only as good as the weakest style in the codebase**. One helper that glues a predicate together from parts undoes the guarantee that every other query is compile-checked, because that helper's text never existed at build time for anything to check. ## The four moves that actually work 1. **Make the compiler do it where you can.** If field references are generated symbols, regenerate them against the new schema and let compilation enumerate the call sites for you. This is the only method that is exhaustive rather than best-effort, and it is the strongest single argument for a generated DSL in a codebase that expects schema churn. 2. **Parse every declared query in the build.** Boot the application, or run the layer's validation, inside the test suite. That turns "does this text still resolve?" into a build result for every query the layer can enumerate - no code generation required. 3. **Capture the statements the tests actually emit.** Log or record emitted SQL during an integration run and keep the set of distinct statements as an artifact. It catches the runtime-assembled queries that no static search can, in proportion to how good the test coverage is - which is the honest limit of the technique, and worth stating out loud rather than pretending it is complete. 4. **Ask the database what has been running.** Engines expose the statements they have executed. On a live system that inventory is real evidence rather than inference, and it covers code paths no test exercises - at the cost of only seeing what has run inside the retention window. ## Then make the change survive a miss Even with all four, assume you missed one, and shape the migration so a miss is loud and reversible rather than silent and destructive. The standard discipline is to expand, migrate, then contract: 1. **Expand.** Add the new column alongside the old one; write both from the application. 2. **Migrate.** Backfill, and move readers over one at a time. 3. **Contract.** Drop the old column only after a period in which nothing has read it. Any query you missed keeps working during the expand phase, and the read that still points at the old column shows up in the engine's statement inventory before you drop it. Contrast that with an in-place rename, where the miss becomes a failing request the moment the migration lands. ## What to build once, not per change - A **build step that validates every declared query** - the cheapest permanent upgrade in this whole area. - A convention that **no field name appears as a quoted string outside the data-access layer**, so the search surface is bounded and reviewable. - A **statement inventory from the test suite**, diffed on change, so an unexpected new statement shape is a review conversation rather than a production discovery. - A written rule that **runtime-assembled query text is the exception**, declared where the team can see it, because each instance is a hole in every inventory method above. ## What to say in the interview The strong answer names the ranking - compiler, then boot, then text search, then runtime evidence - admits that mixed styles reduce you to the weakest one, and finishes with the migration shape that makes a missed query survivable. The weak answer is "grep for the column name", which is only true when every query is a literal string in the repository, and is exactly the assumption that breaks on the one query built from fragments.