Why might values written into selected rows from another labelled column not land in the order they were written?
answer
- two questions: which cells, which value
- laid down, or reconciled
- labels can decide the pairing
- no overlap leaves absent, not an error
- a matching count proves nothing
basics
~20 sThe right-hand side may be reconciled with the target by row label rather than laid down in order. Labels that do not overlap then produce absent cells rather than an error, and labels in a different order put values on different rows.
solid answer
~40 sA write answers two questions, not one: which cells are addressed, and which value goes into each. The second question has more than one answer across this family. Where both sides carry **row labels** — the per-row identifiers a table keeps alongside its columns — the incoming values are matched to the target by label, so a right-hand side that was ordered or restricted differently lands its values on other rows, and labels present on one side only produce absent cells with nothing raised. Where neither side carries labels, matching is strictly positional and a length mismatch is an error. Some designs accept only a single value or an exactly matching length and reject anything else. Decide which regime you are in before you write, and read the rows back afterwards.
go deeper
Know that a write takes its values from somewhere, and that where the incoming values carry row identifiers of their own, they may not simply fill the addressed cells top to bottom.
Explain the reconciliation regimes: matched by row label where both sides carry labels, matched by position where neither does, and rejected outright by designs that refuse to guess.
Recognise the symptoms without being told: absent cells where values were written, correct counts with wrong values, and untouched rows that look deliberate. Then force the pairing and read back.
Set the expectation that a right-hand side is a pairing decision. Prefer a single value or a bare ordered sequence in shared code, and require the pairing rule to be evident from the statement.
## A write asks two questions Writing into a selection looks like one operation and is really two decisions: 1. **Which cells are addressed** — settled by the selection, and usually the part people check. 2. **Which value goes into each addressed cell** — settled by how the right-hand side is reconciled with the target, and usually the part nobody checks. When the right-hand side is a single value, the second question is trivial: every addressed cell gets it. The moment the right-hand side is itself a sequence of values, the reconciliation rule starts to matter, and it is not the same rule everywhere. ## Three reconciliation regimes | what the two sides are | how they are reconciled | what a mismatch does | |---|---|---| | both carry row labels | matched by row label, so each value follows its own label | labels present on one side only leave the cell absent — no error | | neither carries labels | matched strictly by position, first with first | a length mismatch is an error, unless a single value is stretched across the whole selection | | designs that refuse to guess | a single value, or a sequence of exactly the addressed length | anything else is rejected outright | This is the claim to be careful with: it is true of label-carrying designs that the values follow their labels, and false of designs that match by position, where the first incoming value governs the first addressed row whatever either side is called. Neither behaviour is a bug. What is a bug is writing code that is only correct under one of them while believing it is universal. ## What the failure actually looks like Because the reconciliation is by label rather than by order, the symptoms are not the ones people expect: - **Absent cells appear where you wrote real values.** The incoming values simply had no label matching those rows, so nothing was supplied — and supplying nothing is not an error condition. - **Values land on the wrong rows.** If the right-hand side was ordered differently — say it came from a step that put rows in some other order — the values track their labels and arrive somewhere else, while the count of changed cells looks exactly right. - **Some rows keep their old value.** These are rows whose label the right-hand side did not carry, and they are indistinguishable by eye from rows that were meant to be left alone. - **The counts agree.** Three hundred addressed rows, three hundred incoming values, and a completely wrong result — a matching count is not evidence of a correct pairing under label reconciliation. ## Making the reconciliation explicit Do not let the regime be discovered by accident: 1. **Decide which regime the statement is in.** Does the right-hand side carry labels of its own? Does the target? 2. **Force the pairing you want.** Either strip the right-hand side to a bare ordered sequence of values, so positional pairing is the only possibility, or ensure it carries exactly the target rows' labels, so label reconciliation agrees with the order you intended. 3. **Read the affected rows back** from the table and compare the values against what you meant to write. This is the step that catches all three symptoms at once. A useful discipline is to make the right-hand side as dumb as possible: a single value where a single value will do, and otherwise a plain sequence with no identity of its own. The less the incoming side knows about rows, the fewer opinions it can have about where its values belong. ## Why it stays hidden The write completed. The addressed rows were correct. No dimension changed and nothing was raised. The only trace is the values themselves, and values are what people check last — usually after an aggregate somewhere downstream comes out wrong and the investigation walks back upstream. Treat a labelled right-hand side as a deliberate choice you are making about pairing, not as a convenient way to move numbers between two tables.
- The right-hand side has exactly as many entries as there are selected rows. Is that enough?Not on its own. Where reconciliation is by row label a matching count means nothing: the values follow their labels, so a right-hand side that was ordered or restricted differently lands elsewhere, and entries whose labels are absent from the target contribute nothing at all. A matching count is sufficient only where the two sides are paired by position.
- How do you force positional pairing when the target carries row labels?Strip the right-hand side down to a bare ordered sequence of values with no labels, so there is nothing to reconcile against and position is the only available rule. The alternative is to give it exactly the target rows' labels, which makes label reconciliation produce the order you wanted. Both make the intent explicit rather than inherited.
saying these in an interview costs you the question
- Assumes the right-hand side is always laid down row by row in order.
- Expects an error whenever the two sides do not line up.
- Thinks a matching length guarantees values land on the intended rows.
- Believes every design reconciles the two sides the same way.
- Reads absent cells after a write as a problem in the source data.
- Uses a reordered intermediate as a right-hand side without relabelling it.