Turning month columns into rows
A practical workshop for analytics expects tidy long-form data. Build the smallest manifest, validate it, run it and read the result.
Context — analytics expects tidy long-form data
The task is currently manual and its assumptions are not recorded. Hydra turns it into files that can be reviewed and rerun.
Where things stand
- The current result is fragile. Its assumptions are split between tools, clicks and memory.
- Reruns are uncertain. The write mode or orchestration rule is not visible beside the data.
- Evidence is missing. A colleague cannot compare a declared rule with a concrete before and after state.
The question
How do you express this rule with Hydra’s unpivot operation and prove exactly what it changes?
- Use one minimal input fixture
- Declare one operation per step
- Validate the DSL before running
- Compare the complete before and after states
The solution in one line
One unpivot step between a deterministic CSV source and a replaceable CSV destination.
product,Jan,Feb Lamp,20,30 Chair,50,40
Use a minimal fixture that exposes the rule.
Steps
1. capture the before state
- Use a minimal fixture that exposes the rule.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
product,Jan,Feb Lamp,20,30 Chair,50,40
2. declare the fixture
- Read the known input.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
version: "1.0"
sources:
input:
type: csv
connection:
base_path: "data"
extract:
table: input.csv input3. add the unpivot step
- Write one operation with explicit parameters.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
version: "1.0"
steps:
- unpivot:
id_vars: [product]
value_vars: [Jan, Feb]
var_name: month
value_name: revenue unpivot operation declared4. make the result observable
- Write a replaceable CSV.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
version: "1.0"
destinations:
result:
type: csv
connection:
base_path: "out"
load:
table: result.csv
mode: replace
---
version: "1.0"
pipeline:
from: input
to: result 5. validate the operation
- Ask Hydra to parse the step.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
$ hdrctl test unpivot-workshop ok transformations.yaml — 1 step(s) valid Operations: unpivot ✅ All tests pass — ready to execute.
6. run and compare after to before
- Inspect the exact output.
- Compare the file with the explanation in the workbench.
- Record the shown check before moving to the next step.
$ hdrctl run unpivot-workshop ✅ Pipeline completed successfully product,month,revenue Lamp,Jan,20 Chair,Jan,50 Lamp,Feb,30 Chair,Feb,40
Expected result
- The after state matches the stated rule.
- One operation is counted by `hdrctl test`.
- The fixture can be rerun without accumulating rows.
Reading the results
Compare columns, row count and ordering—not just one visible value. Identifier columns are repeated; every selected value column becomes a row.
What the counters do—and do not—prove
They prove how many records entered and left this run. They do not replace checking the target schema, the business meaning of values or the reason a workflow step was skipped.
The rule to carry forward
Identifier columns are repeated; every selected value column becomes a row.
Did we answer the question?
| objective | result | where |
|---|---|---|
| Configuration explicit | yes | the relevant YAML block |
| Safe rerun | yes | the destination or workflow policy |
| Observable result | yes | the command output and counters |
| Hidden manual rule | removed | the rule now lives in versioned text |
Before and after
- Before — analytics expects tidy long-form data requires a person to remember the order, options and checks.
- After — one reviewed manifest and one command produce the same observable result.
- What is really gained — The durable gain is the contract: a colleague can read the configuration, reproduce the run and challenge the assumptions.