How Much Urgent Work Was Hidden Inside the Pump Documents?

The maintenance screen stores each pump with a small list of recent visits. The supervisor asks how many minutes of urgent work occurred at north. A pump can contain both urgent and routine visits. Adding its whole history after finding one urgent visit would overstate the requested work.

We can transform the records in stages. First choose the site. Then expose individual visits, keep urgent ones, and collect their minutes. At each stage we should be able to point to one output row and say what it represents.

Filter the site, expand its visits, retain urgent members and sum their minutes by site.

[
  {
    "key": "north",
    "total": 20
  }
]

We want urgent visit minutes for the requested site. The unit being counted is a visit minute. We are not counting pumps, summing every visit on a pump that once needed urgent work, or combining sites.

The fixture has bounded recent visits embedded in pump documents. A production report over a full history might read a separate visit collection instead. The pipeline should follow the actual source representation and retention policy.

The report description tells us which records must enter the final aggregate.

Site belongs to the parent pump, so we can reject other sites before touching their visit arrays. This reduces the input to later stages without changing the selected visit population.

In a real MongoDB pipeline, a suitable early $match may use an index and the optimiser may move eligible filters. Our model states the order explicitly so we can inspect correctness first. It does not promise a particular execution plan.

A filter can move earlier only when the fields and meaning it needs are already available.

An unwind step produces an output for each array member while retaining the parent’s other fields. P1 therefore produces separate rows for its urgent and routine visits. The visit field now contains one member instead of a list.

Our local tool requires an array on every document and emits no rows for an empty array. MongoDB $unwind has additional behaviour and options, including preserving certain empty, null or missing cases. Read those rules before assuming the teaching model covers every stored value.

After expansion, one row represents a visit. Repeated parent fields are context, not additional pumps.

MongoDB accepts an ordered array of stage objects. The first $match selects site. $unwind exposes visits. The next $match keeps urgent members. $group collects their minutes, and an explicit sort gives the result a presentation order.

A pipeline ordinarily returns computed results without changing the input collection. Stages such as $merge or $out can write results and need their own permissions and deployment decisions; this example uses neither.

The following JSON is the pipeline argument passed to an aggregate operation.

[{"$match":{"site":"north"}},{"$unwind":"$visits"},{"$match":{"visits.kind":"urgent"}},{"$group":{"_id":"$site","total":{"$sum":"$visits.minutes"}}},{"$sort":{"_id":1}}]

After filtering, add visits.minutes under each site key. The routine visit no longer exists in the input to this sum. If no urgent visits remain, this pipeline has no group and returns an empty result. An explicit zero row would require a separate preserved site population or another stated default.

Likewise, if a parent carries an annual budget, summing that budget after unwind repeats it once per visit. Reduce at the correct grain or keep that parent-level branch separate.

The field’s location in a repeated row does not change what it measures.

The dictionary below accumulates minutes for the surviving visit rows. It is a model of the group stage; its input has already passed site and kind checks. Sorting the keys makes output order deterministic.

The later challenge includes the earlier filtering and array steps, so a correct sum alone will not solve it.

Each input contributes exactly once to its group.

rows = [{"site":"north","minutes":12},{"site":"north","minutes":8},{"site":"west","minutes":3}]
totals = {}
for row in rows:
    totals[row["site"]] = totals.get(row["site"], 0) + row["minutes"]
print(sorted(totals.items()))

[('north', 20), ('west', 3)]

A small number of parent documents can contain many array members. Expansion increases rows for later filtering and grouping. Grouping and sorting can also need substantial working memory. Use bounded records, useful early predicates and measured server plans to control the workload.

MongoDB has stage-specific resource behaviour and deployment options. Treat those as implementation details to inspect for your version. A fast run on four invented visits does not establish the capacity of a production report.

Count intermediate records as well as final groups when diagnosing the expensive stage.

The first workshop contains only urgent visits, so summing every visit after choosing the site happens to work. The changed fixture inserts a large routine visit into P1. The construction must exclude that member even though P1 still has urgent work.

Then try an empty visit array and a site with no urgent visits. Decide whether the report should contain no group or a preserved zero row before writing a test for it. This lesson deliberately returns no group.

Keep the output contract visible as the pipeline grows. Later stages cannot repair minutes already counted from the wrong population.