Connect data by identity
Why does joining rows by position send orders to the wrong person?
Entering midway? Revisit Find an item without checking everything for the preceding worked example, or start here and use the explanation below.
Start with a concrete question
Original customers [101 Ada,102 Bo,103 Cy] and orders [103:30,101:10] have different ordering. A second order for customer 103 can be added.
Try the initial inputs, then write a prediction before changing one setting. All calculations run locally on your CPU.
What do you expect?
Predict whether sorting one list is enough to preserve a join.
Change one thing. Inspect what happens.
- Inspect wrong owners under positional matching.
- Switch to key matching and add the second order.
- Implement a nested-loop ID join in the code runner; add an unknown ID and return an explicit unmatched count.
Your settingsMechanism
Calculation belowEvidence
Compare outcomes
Compare the current results
Every bar starts at zero and uses the same numeric scale in this chart. The upper bound automatically adjusts to the largest current value (at least 1), so compare the numbers when changing inputs. Units and quantities come from each label; different kinds of quantity are not interchangeable. Displayed values are rounded to at most six significant digits.Follow the calculation
- Order customer 103, amount 30: match row position → Ada; WRONG owner.
- Order customer 101, amount 10: match row position → Bo; WRONG owner.
Row position is not identity. Multiple orders for one customer are valid; distinguish a repeated customer key from a duplicated event.
Build and validate a keyed interface
Repair positional matching with a nested loop over customer IDs. Print the matching name or unmatched. Order ID 999 has no customer; do not assign it to someone else. Expected output: Cy, Ada, unmatched. Add a second order for 103 and preserve it.
170/8,000 characters. Drafts save locally and are included in backups. Importing or opening a draft never runs it.
Bounded JavaScript subset: variables, primitive arrays, conditions, loops, functions and print. No browser objects, network, imports or eval. Maximum 10,000 operations, 64 array items, call depth 16, strings of 256 characters, 40 output lines / 4,000 output characters and 160 trace frames.
Compare with my earlier draft
const customerIds = [101, 102, 103];
const names = ["Ada", "Bo", "Cy"];
const orderIds = [103, 101, 999];
for (let i = 0; i < orderIds.length; i++) {
print(names[i]);
}Explain what you changed and why in your observation notes. Text differences do not establish quality.
Inspect an example solution after your attempt
const customerIds = [101, 102, 103];
const names = ["Ada", "Bo", "Cy"];
const orderIds = [103, 101, 999];
for (const id of orderIds) {
let match = -1;
for (let j = 0; j < customerIds.length; j++) {
if (customerIds[j] === id) { match = j; }
}
if (match === -1) { print("unmatched"); }
else { print(names[match]); }
}This is one worked example. Test another input and explain its limitations.
Captures keep your inputs, prediction and observation. Results are recalculated from those inputs. Resetting inputs keeps your captures and challenge history.
Explain the mechanism
Connect data by identity
Original customers [101 Ada,102 Bo,103 Cy] and orders [103:30,101:10] have different ordering. A second order for customer 103 can be added.
Predict before changing inputs
Predict whether sorting one list is enough to preserve a join.
Understand the mechanism
Identity says which entity a record describes. Position says where it happens to appear in a list. They are not interchangeable.
Order 103 belongs to Cy even though it appears first. Positional matching sends it to Ada. A second order for 103 is legitimate unless its event identity also repeats.
An interface contract must specify key type, uniqueness requirements, missing-key behavior and units. Never silently attach unmatched records to an arbitrary owner.
Calculate it yourself
For each order, find customer where customer.id equals order.customerId; do not assume equal row indices.
Guided investigation
Inspect wrong owners under positional matching.
Switch to key matching and add the second order.
Implement a nested-loop ID join in the code runner; add an unknown ID and return an explicit unmatched count.
Assumptions and limitations
All input IDs currently match; the coding task adds the missing-key case.
No real personal information, database or network request is used.
Further investigations
High school: Connect invented library borrowers and loans by stable ID.
College: Implement join tests for reordered, missing and repeated entity keys.
Working professionals: Write a data-interface contract with schema checks and rejected-record reporting.
Your implementation or data task
Repair positional matching with a nested loop over customer IDs. Print the matching name or unmatched. Order ID 999 has no customer; do not assign it to someone else. Expected output: Cy, Ada, unmatched. Add a second order for 103 and preserve it.
Use the editable workspace on this page. Its output is practice evidence; explain why it satisfies the contract and test a fresh case.
Try a fresh case
Customer IDs are [10,20,30]. An order has customer ID 30. What zero-based customer index matches?
This is a public practice check. Retries support learning; matching a number does not certify independent proficiency.
Take the investigation further
Choose any extension. These are project prompts for you to carry out; they are not automatically assessed.
School investigation
Connect invented library borrowers and loans by stable ID.
College investigation
Implement join tests for reordered, missing and repeated entity keys.
Workplace investigation
Write a data-interface contract with schema checks and rejected-record reporting.
Keep the evidence, choose your next step
Completion records your own decision that you have worked through this investigation. Practice checks and independent project evidence are separate.