A subset of rows is bound to a new name, then a column on that name is set to zero — what does the write target?
answer
- two statements, two objects
- the original is never named
- window on bytes, or fresh storage
- silence is not evidence
- read back from the original
basics
~10 sThe write targets whatever the first statement produced — the original table is not named in the second statement at all. Whether the original changes depends entirely on what that intermediate object was.
solid answer
~40 sTwo statements, two objects. The first evaluates an address and produces a result object; the second stores a value into *that* object. The original table is never mentioned in the second statement, so it changes only if the intermediate was **a window onto the same bytes** — a result that reads and writes the original's storage. If the selection was instead handed back as **storage of its own**, meaning freshly allocated bytes, the store still succeeds, lands in the intermediate, and is discarded with it. Nothing is raised either way, because from the runtime's point of view nothing failed. The portable way to find out is a read-back: re-read those rows from the original table, by its own name, and compare them with what you meant to write.
go deeper
Recall that a selection and an assignment are two separate steps, and that the second stores into whatever the first produced. Then re-read the rows from the original table to check the value is actually there.
Explain the two possible results of a selection — a window onto the original's storage, or freshly allocated bytes of its own — and why two identical lines therefore have two different outcomes.
Demonstrate the verification habit: re-read the addressed rows from the original and compare values, rather than trusting that no error appeared or that a diagnostic would have caught it.
Weigh what a codebase should require here — which write forms a review accepts, and where a read-back is mandatory — against the reading and runtime cost that rule puts on every update.
## Two statements, two objects A selection and an assignment are separate operations, and they run in that order. The first statement evaluates an address — *the rows of this table where some condition holds* — and produces a **result object**. Binding that object to a name is bookkeeping; what matters is that a second object now exists alongside the table. The second statement then stores a value into one of *that* object's columns. Read the second statement literally. The original table's name does not appear in it. Nothing in it asks the original to do anything at all. So whether the original changes is not a property of the assignment — it is entirely a property of what the first statement handed back. ## A window onto the same bytes, or storage of its own Two outcomes are possible, and the code is identical in both. - **A window onto the same bytes**: the result reads and writes the original's storage, so a store through it is a store into the original. - **Storage of its own**: the result holds freshly allocated bytes, so a store into it is real, complete, and unreachable from the original. | what the first statement produced | what the store does | what a later read of the original shows | |---|---|---| | a window onto the same bytes | reaches the original's storage | the new value | | storage of its own | lands in the intermediate | the old value, unchanged | Which of the two you got is not something the assignment can reveal. It turns on whether the selection can be described as a start, a count and a step — the only shape that can be handed back as a window — and beyond that on what the design chose for that particular expression. **Designs in this family genuinely disagree here.** Some hand back a window wherever the shape allows it; some allocate eagerly and always return storage of its own; some promise a duplicate and allocate only when one side is written; and some are immutable by default and offer no in-place write at all, so the second statement quietly produces a new object that is then dropped. The same two lines can be correct under one tool and a no-op under another, which is why "this pattern has always worked for me" is not an argument. ## Why nothing is raised No error appears because nothing failed: 1. the address evaluated successfully and produced a well-formed object; 2. the store into that object succeeded; 3. the object then went out of scope and was reclaimed, which is ordinary. There is no step at which a design is obliged to notice that you meant the original. Some designs do try: they recognise the two-step shape heuristically and emit a diagnostic. That diagnostic is evidence, not a decision procedure — it misses real cases and it fires on safe ones. Other designs emit nothing at all, either because the behaviour is defined (the two-step write reliably never reaches the original, so there is nothing anomalous to report) or because, being immutable by default, they do not regard a discarded result as a fault. **Silence is not confirmation.** ## The read-back The portable proof is to go and look at the original: 1. perform the write; 2. re-read the affected rows from the **original table, by its own name** — never through the object you wrote into; 3. compare the values you read against the values you intended. The ways people fool themselves are all variations on step 2: - reading back through the intermediate, which always shows the new value because that is exactly where the store landed; - confirming only that the statement executed, which says nothing about its target; - assuming a diagnostic would have fired if anything were wrong; - checking one cell that did change and generalising to the rest. ## The habit this builds Once the mechanism is clear the defensive form follows: say the whole address in a single statement so the table itself performs the write, and keep a read-back for anything whose result a later step will consume. Neither is about elegance. The two-step form fails **silently and at the level of individual values** — no exception, no missing rows, no change in the size of anything — which is the hardest class of defect to find afterwards, because by the time a number looks wrong the statement that produced it is several steps upstream and reads perfectly.
- If the selection is never bound to a name and the whole thing is written as one long expression, is the write safe?No. The hazard comes from the number of addressing steps, not from the name. An expression that addresses once and then addresses the result again produces the same discardable intermediate; binding it to a name only makes that intermediate visible. Safety comes from handing the full address to the original object in a single write.
- What is the difference between reading back from the original and reading back from the object you wrote through?Reading through the intermediate always shows the new value, because that is where the store landed — it confirms only that the assignment ran. Re-reading the addressed rows from the original table, by the original's own name, is the step that distinguishes a write which reached the data from one that was discarded.
Correcting a form and correcting a photocopy of that form feel identical while you are doing it. Both corrections are real ink. Only one of them is on the sheet anyone else will read, and nothing about the act of writing tells you which sheet is under your pen. You have to go back and look at the original.
saying these in an interview costs you the question
- Assumes assigning through any selection always updates the original table.
- Treats the absence of an error as proof the value landed.
- Thinks binding the selection to a name is itself what breaks the write.
- Says reading the value back out of the intermediate proves the original changed.
- Relies on a tool emitting a warning whenever a write is lost.
- Claims one tool's behaviour here is how every design behaves.